Agent entitlement audit: what your agents can actually reach · Enterprise Agentic AI Insights
Google, NVIDIA and OpenAI shipped agent entitlement controls this week; AWS did the same in April. None is on by default. The Storm-3168 numbers, a side-by-side, and a free blast radius check with no email required.
Your Q4 platform refresh just acquired a line item nobody costed. Between September 25 and September 29, three platform vendors shipped or previewed the same kind of control, independently. Google added resource-level roles to Gemini Enterprise. NVIDIA put agent identity verification into DOCA and a quarantine watchdog onto separate silicon. OpenAI restricted unsupervised background work to read-only tools and previewed employer-provisioned agent identities. AWS had already shipped On-Behalf-Of token exchange into Bedrock AgentCore on April 30. Each one narrows what an agent is allowed to reach. In the same week, Microsoft published the incident that explains why. The seven minutes Microsoft found that a service principal's client ID, client secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee. The issue was edited afterward. The secret stayed readable in the issue's edit history. Microsoft listed this as possible initial access and said it could not confirm whether that secret was used for the activity it describes. What followed is worth reading as an operations problem rather than a security story, because the numbers are all Microsoft's own. The compromised principal spent about fifteen hours and thirty minutes performing over three hundred successful read operations, enumerating virtual machines, subscriptions, resource groups and resources. About ninety minutes into that, a second compromised principal enumerated virtual machines and resource groups across two subscriptions in five seconds. About sixteen hours after that early reconnaissance, the second principal ran more inventory. Then the core destructive sequence ran for roughly seven minutes. Over one hundred storage account deletion attempts. Across the full destructive window, more than one hundred and fifty destructive or credential-collection operations in thirty-five minutes. Most of the storage accounts targeted were successfully deleted. One thing held. Azure resource locks and storage account level deletion protection, in Microsoft's words, "blocked deletion attempts for few of the storage accounts, demonstrating the value of independent safeguards." No model was jailbroken. No guardrail was argued around. A credential was broader than the job it was doing, and a safeguard that would have contained it was, in most cases, not switched on. Why the control surface moved If you run the platform, this is the useful part. The vendors have stopped treating agent safety as a model property and started treating it as an entitlement property. Read the side-by-side rather than the logos. Each cell reports only what that vendor published, and dates it. AWS is in the matrix because it shipped the same pattern in April, not because it shipped this week. Where a vendor has not addressed something, the matrix says not in this source rather than guessing. | | Google Gemini Enterprise | NVIDIA Open Agent Safety | OpenAI Dots | AWS Bedrock AgentCore Identity | |---|---|---|---|---| | Dated | 28 Sep 2026 | 28 Sep 2026 | 29 Sep 2026 | 30 Apr 2026 | | What shipped | Resource-level IAM on apps and data stores | Identity verification in DOCA; Sentry watchdog on separate silicon | Unsupervised background work limited to read-only tools; specialist identities in preview | On-Behalf-Of token exchange | | On by default | No. Existing project-wide grants remain | Components staged, when-and-if-available | Specialist preview; enterprise is admin-enabled beta | Application must propagate user context | | Not in this source | Hardware kill path | Named production deployments | Resource-level cloud IAM | Out-of-band silicon quarantine | The pattern is consistent. Identity issued to the agent rather than inherited from a person. Scope granted below the project or tenant. Enforcement that sits somewhere the agent cannot reach. The catch that lands on your desk Not one of these controls turns itself on. Google's resource-level roles are a new capability. Every existing Gemini Enterprise deployment keeps the project-wide grant until somebody reconfigures it. NVIDIA's components are staged and offered on a when-and-if-available basis, and the hundred-plus organizations named are collaborators, not deployments. OpenAI's specialist identities are a preview, and the enterprise tier is an admin-enabled beta. AWS On-Behalf-Of requires the application itself to propagate user context. The controls are on the price list. The configuration work is not on anyone's calendar. That gap is the exposure. Where this becomes a board matter Only now does the regulation belong in the conversation. Article 50 of the EU AI Act has applied since August 2, 2026. The date still ahead is the grace period: AI systems placed on the market before August 2 must meet the marking and detection obligations only as from December 2, 2026. That is sixty-three days. Providers must ensure AI-generated or manipulated content is "marked in a machine-readable format and detectable as artificially generated or manipulated," and that people are told clearly when they are interacting with AI. National market surveillance authorities enforce it. Penalties reach up to fifteen million euros or three percent of total worldwide turnover. That clock is marking and disclosure. It is not a substitute for knowing what each agent can reach. Add to that a separate item your vulnerability process will probably not see at all. The MCP Python SDK advisory published September 28 lets a malicious MCP server choose where your OAuth credentials are sent. It is rated CVSS 7.5. It has no CVE. Upgrading to 1.30.0 or 2.2.0 is not sufficient: for ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider you must also pass issuer=, and you must clear stored OAuth client information once so the client re-registers, because registrations created before the fix are not bound to an issuer. A ticket that closes on "upgraded to 1.30.0" leaves the exposure in place. The list that would have contained Storm-3168 is still the list of what each agent can reach and write. The move Start with five columns and one afternoon, not a maturity model. For each agent: its name and the human who owns it. The identity it runs as, and whether anything else shares that identity. Every resource that identity can reach, and which of them it can write to. What stops it, and whether that stop runs outside the agent. Where its actions are logged, and who cannot edit that log. An agent nobody will put their name against is a decommissioning decision, not a register entry. That is usually the most valuable output of the first afternoon. Then run the blast radius check below. Four inputs, no email. It gives you the number of agents whose entitlements you cannot name, what a single credential reaches, and the three entitlements to cut first. <div data-ariana-embed="agent-entitlement-blast-radius-check" <p<a href="/assets/tools/agent-entitlement-blast-radius-check.html" target="blank" rel="noopener"Open the agent entitlement blast radius check →</a</p </div