AI agent resource-level access control is the missing governance layer

At a glance

What this is: This analysis argues that MCP and OAuth are not enough for AI agents because tool allowlists do not reveal which resources an agent can truly touch.

Why it matters: It matters because AI agents now act inside real enterprise workflows, so IAM, NHI, and application access teams need resource-level controls that match dynamic agent behaviour across systems.

👉 Read Andromeda Security's analysis of AI agent resource-level access control

Context

AI agent resource-level access control is the real governance gap here: a policy can approve a tool call while still failing to constrain the data, project, bucket, or record behind it. The article shows that this mismatch is most visible when an agent uses MCP and OAuth correctly but still reaches regulated data or destructive actions that the allowlist never examined.

That matters for identity security because the problem is not only proving the agent is authenticated. It is deciding what the agent may do to a specific resource in the moment, especially when the agent is acting on behalf of a human and the target is chosen dynamically during execution.

Key questions

Q: How should security teams govern AI agents at the resource level?

A: Security teams should govern AI agents by evaluating the specific resource being touched, not just the tool or connector being used. The policy must bind agent identity, acting human context, action type, and target object together so a permitted connector cannot reach an unapproved table, repository, bucket, or record.

Q: Why do tool allowlists fail for AI agent access control?

A: Tool allowlists fail because they authorise the verb, not the object. An agent can be permitted to call a tool such as execute_sql while still targeting sensitive data or destructive commands inside that tool call. The security decision happens too early if it never inspects the resource the agent is actually affecting.

Q: What breaks when OAuth scopes are broader than resource permissions?

A: When OAuth scopes are broader than resource permissions, the connector can succeed while the downstream application allows access to objects the security team never meant to expose. That creates a split control plane where one layer says yes to invocation and another layer says yes to access, with no single governance decision in charge.

Q: Who is accountable when an AI agent touches the wrong resource?

A: Accountability should sit with the programme that approved the delegated access path, the application owner that exposed the resource, and the identity team that defined the policy boundary. If those roles are not clearly assigned, incident review will focus on the agent itself instead of the governance failure that allowed the action.

Technical breakdown

Why MCP tool allowlists stop at the wrong layer

MCP standardises how agents discover and call tools, but it does not inspect the semantics inside the request body. That means an allowlisted execute_sql call can still target CUSTOMER_PII.USERS, just as a repository or bucket argument can point at a sensitive resource. The protocol layer sees structured fields, not governance intent. In practice, that leaves security teams with a control that authorises the verb but not the object of the action.

Practical implication: Treat MCP as transport and tool orchestration, not as the final authorisation boundary.

Why OAuth scope and application permissions diverge for agents

OAuth often answers whether the agent may invoke the connector, while the downstream application decides what the mapped identity can access. That split works poorly when one connector covers many resources and the resource selection happens at runtime. IAM bindings, table grants, repository ACLs, and group memberships still matter, but they operate below the tool decision. The result is a layered policy model with a blind spot in the middle.

Practical implication: Map agent policy to the downstream resource controls that actually enforce data and object access.

Resource-level control for dynamic agent actions

The hard part is that the agent chooses its target dynamically from context, upstream data, or user request. That makes least privilege harder to define at provisioning time because the exact object is not always knowable in advance. In human IAM, the request and the target are usually separable. For agents, the request can be generated after the target is discovered, which means the policy must evaluate the resource at the same time as the action.

Practical implication: Build policies that bind agent, human context, tool, and resource together at decision time.

NHI Mgmt Group analysis

Tool-level authorisation is no longer a sufficient governance boundary for AI agents. The article shows a control plane that can approve execute_sql, repository access, or SaaS connector use while remaining blind to the specific table, record, or bucket involved. That is a structural governance failure, not a narrow implementation bug. Practitioners should treat the tool as the transport layer and the resource as the real access object.

Least privilege was designed for stable targets, but agentic workflows select targets at runtime. That assumption fails when the agent discovers the resource in the moment, then acts immediately on the newly identified object. The implication is not simply tighter policy, but a rethink of how privilege is expressed when the target of action is not fixed before execution begins.

Resource-level access control is the named concept this article exposes. It is the missing policy layer between connector authorisation and downstream application permissions, where the system must decide whether a specific agent may act on a specific resource in a specific session. Without that layer, organisations are governing the door while leaving the rooms inside effectively unclassified. Practitioners need to align authorisation with the object actually being touched.

Application access management now extends beyond human sessions into delegated agent behaviour. The article’s strongest insight is that enterprise access models already know how to govern resources, but they have not yet been consistently adapted to agent-mediated execution paths. This collapses the old boundary between identity proof and action scope. Security teams should assume that agent identity, human delegation, and resource entitlement must be evaluated together.

Agent security is becoming an application governance problem, not only an identity proofing problem. The article correctly separates cryptographic identity from permission to act, which is the right analytical move. Identity gets the agent authenticated. Governance decides whether the requested action is acceptable against the actual resource. Practitioners should stop treating agent identity as the finish line and start treating it as the prerequisite.

From our research:

• From our research: 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the same research.
• For the broader governance picture, see OWASP Agentic AI Top 10 for the control failures that make resource-level access hard to enforce.

What this signals

Resource-level access control: this is the governance gap that will determine whether agentic AI becomes manageable or merely observable. Once an agent can choose a target dynamically, the policy boundary has to move from connector approval to object-level authorisation, which changes how IAM, IGA, and app owners share responsibility.

With 92% of organisations already saying AI agent governance is critical, the programme risk is no longer awareness but control design. Teams that keep authorising tools without binding them to resource context will keep discovering policy gaps only after data movement or destructive action has already occurred.

The practical signal to watch is whether your current controls can produce a single answer to who, what, and which object for every agent action. If they cannot, the environment is already operating with split authorisation, and split authorisation is where incident review starts.

For practitioners

• Define resource-aware authorisation rules Require policies to evaluate the exact database table, repository, bucket, or SaaS record the agent is touching, not just the connector or tool name. Pair the agent identity with the resource object and the acting human where delegation is involved.
• Classify high-risk agent actions by resource type Separate low-risk read operations from writes, deletes, entitlement changes, refund actions, and migration tasks. Use the resource class to decide where approval, step-up review, or additional constraints are mandatory.
• Align connector policy with downstream IAM Review whether the downstream application permissions, role mappings, and object grants are actually enforcing the same decision the MCP layer thinks it made. Where they diverge, the effective control is the weakest layer.
• Log the action context needed for review Capture the human principal, agent identity, tool call, resource target, and resulting permission decision in the same event record so investigators can reconstruct what the agent was allowed to touch.

Key takeaways

• AI agents expose a governance gap between tool approval and resource approval, and that gap is now central to application access control.
• The evidence shows that agent behaviour is already exceeding intended scope at scale, which makes resource-level policy design an immediate programme issue.
• Practitioners should bind agent, human context, tool, and target resource into one decision model or accept that allowlists alone will not control agent action.

Key terms

• Resource-level access control: An authorisation model that decides access based on the specific object being touched, such as a table, repository, bucket, or record. For AI agents, it matters because tool approval alone does not explain whether the target resource is sensitive, destructive, or outside the intended scope.
• MCP: Model Context Protocol is the standard way many AI agents discover and call tools. It helps coordinate agent-to-tool communication, but it does not itself decide whether the resource inside the tool call is appropriate. That makes MCP useful for orchestration and incomplete as a governance boundary.
• Delegated access: Access granted to one identity so it can act on behalf of another principal, typically a human user or a higher-level system. In AI agent contexts, delegated access becomes risky when the policy boundary only validates the delegate and not the exact resource or action it is permitted to exercise.
• Application access management: The controls that determine what an identity can do inside a specific application after authentication succeeds. For AI agents, this is the layer that should constrain tables, projects, buckets, and records, because proving the agent is genuine does not by itself limit the thing it can alter.

What's in the full article

Andromeda Security's full blog covers the operational detail this post intentionally leaves for the source:

• The exact policy inputs the vendor says an MCP gateway should evaluate on each call
• Example request bodies showing how tool approval can diverge from resource authorisation
• The vendor's architecture framing for tying agent identity to downstream application permissions
• Workflow examples spanning databases, repositories, SaaS records, and cloud storage

👉 Andromeda Security's full post covers the MCP policy gap, resource targeting, and delegated access model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity in your organisation, it is worth exploring.