Notifications
Clear all
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.
NHIMG editorial — based on content published by Andromeda Security: Request a demo Application Perimeter: Why AI Agents Need Resource-Level Access Control
Questions worth separating out
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.
Q: Why do tool allowlists fail for AI agent access control?
A: Tool allowlists fail because they authorise the verb, not the object.
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.
Practitioner guidance
- 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.
- Classify high-risk agent actions by resource type Separate low-risk read operations from writes, deletes, entitlement changes, refund actions, and migration tasks.
- 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.
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
👉 Read Andromeda Security's analysis of AI agent resource-level access control →
AI agent resource-level access control: what IAM teams are missing?
Explore further
06/07/2026 10:00 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent resource-level access control is the missing governance layer
