Topic starter
06/07/2026 9:44 am
TL;DR: AI agents can pass tool-level OAuth checks while still being able to reach the wrong database rows, repository objects, or SaaS records because the policy decision stops at the tool name, according to Andromeda Security. Resource-level access control, not just agent authentication, becomes the governance layer that IAM and app security teams have to solve next.
Editorial analysis by NHI Mgmt Group, based on content published by Andromeda Security: “Application Perimeter: Why AI Agents Need Resource-Level Access Control”.
Key questions
Q: How should teams govern AI agents when tool approval does not cover the resource being accessed?
A: Teams should treat tool approval as only the first gate.
Q: Why do AI agents increase access risk compared with traditional application integrations?
A: AI agents can make runtime decisions, chain tool calls, and reach multiple systems faster than a human operator.
Q: What breaks when access control stops at the MCP tool layer?
A: The control can approve the tool call while missing the actual operation on the data object.
Practitioner guidance
- Define resource-aware policy boundaries Map each agent permission to the specific table, repository, bucket, project, or record it may touch, not just to the connector it may call.
- Bind session context to the acting human When an agent acts on behalf of a person, carry that identity into the policy decision so the allowed resource set reflects delegated intent.
- Separate safe tool use from safe resource use Treat tool allowlists as a transport control and evaluate the underlying object access as a separate authorisation decision.
Bottom line: AI agent risk is not limited to whether the model can authenticate, but to whether it can act on the wrong resource after authentication succeeds.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/07/2026 10:00 am
Resource-level access control is the missing governance layer for agentic AI. The article shows that tool approval and identity proofing are necessary but insufficient when the target object is determined at runtime. That means the real control point is not the connector name but the resource context attached to the action. For identity teams, this is a shift from connector governance to object-level authorisation.
A few things that frame the scale:
- Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
A question worth separating out:
Q: How does resource-level authorisation change the way IAM teams think about agent access?
A: It shifts IAM from approving identities and connectors to approving the exact business object affected by each session. That is an accountability change, because the policy must reflect who the agent is acting for, what it is doing, and which resource is in scope. Without that alignment, delegated access remains too broad.
👉 Read our full editorial: AI agent resource-level access control is the missing governance layer