Teams should enforce access at the identity layer when the question is whether the agent is allowed to act at all, and use the data layer for classification and context. If the policy must be able to deny an action before data is touched, identity and authorization must own that decision.
Where the Identity Layer Ends and the Data Layer Begins
Identity-layer enforcement answers a binary question: may this agent act at all, under this principal, in this context. Data-layer enforcement answers a different question: may this request see, transform, or move this data, given its classification and business context. Treating them as interchangeable creates brittle policy, because the decision point changes what can be denied early and what can only be filtered after access has already started.
That separation matters most when the action itself is the risk. If the policy must stop an agent from opening a ticket, sending a message, or invoking a tool before any record is exposed, the control belongs with identity and authorization. If the main concern is whether a record, field, or document is appropriate for the request, the data layer should carry the classification and handling rules that shape downstream access.
In practice, the cleanest boundary is: identity decides who or what is allowed to do this, data decides what this request may know or touch. A request can be correctly classified and still be unacceptable as an action, and a permitted action can still be constrained to a narrow data slice. Keeping those questions separate reduces policy leakage and avoids overloading one layer with a job it cannot reliably perform.
Why Policy Placement Changes the Security Outcome
When identity owns the deny decision, the system can block standing access, prevent unsafe delegation, and apply least privilege before the agent reaches the target system. That is the right pattern for agents with tool access, write permissions, or the ability to trigger external side effects. It also makes audit and revocation simpler, because the decision is attached to the principal and the action, not inferred later from data handling.
When the data layer is asked to make the whole decision, teams often end up using classification tags as a proxy for authorization. That works only when the request is already legitimate and the problem is narrowing scope. It does not work well when the key question is whether the agent should be allowed to initiate the operation in the first place, especially if the action could create new records, exfiltrate content, or alter a workflow.
The practical test is whether the failure mode is action abuse or data misuse. If the concern is an agent doing something it should not do, use identity and authorization. If the concern is an approved action handling the wrong content, use data controls. AI Agent Authorisation Guide is useful here because it frames per-action decisions, task-scoped access, and delegated authority as the mechanism for stopping unsafe agent behaviour early.
How Teams Should Decide in Real Systems
Use identity-layer enforcement when the control question is about authority, delegation, or blast radius. That includes whether an agent may call a tool, write to a system of record, impersonate a user, or continue operating after a context change. Use data-layer enforcement when the control question is about sensitivity, retention, redaction, field-level scope, or classification-based handling. The former is about permission to act; the latter is about permission to inspect or process specific information.
A useful design rule is to push the earliest meaningful deny as high as possible in the stack. If identity can reject the request before any sensitive data is fetched, that is usually stronger than relying on downstream filtering. If the request is already authorised in principle, then the data layer can still reduce exposure by constraining the minimum necessary content. This is especially important for agentic systems that can chain tools and carry context across steps.
Teams should also separate policy ownership. Identity and authorization teams should own principal-level grants, delegation, and revocation. Data governance or information protection teams should own classification, labeling, masking, and approved-use rules for content. A single agent workflow may need both, but one should not be forced to impersonate the other. Zero Trust for AI Agents is a good reference for this split because it emphasizes verifying the principal and request, removing standing privilege, and enforcing policy per action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent access decisions hinge on whether the principal may act at all. |
| Recommendation — Enforce per-action authorization and least privilege for agent principals. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about limiting agent authority to the minimum necessary. |
| IA-9 — Service Identification and Authentication | AI agents acting as non-human principals need identity-layer enforcement. | |
| Recommendation — Constrain agent permissions to the minimum set needed for the task. Authenticate non-human principals before permitting tool or system access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The identity-versus-data boundary is an access-control design choice. |
| Recommendation — Define whether authorization decisions are enforced centrally or at the target data. | ||
| OWASP ASVS | V8 — Authorization | The core question is where authorization is enforced for agent actions. |
| Recommendation — Validate that every sensitive action is authorized before execution. | ||
Practitioner Guidance
What to verify: Check whether the control must deny an action before any sensitive payload is retrieved. If yes, the policy belongs in identity or authorization, not only in data classification. If the control only narrows what an already-permitted request can see, the data layer is the right place to enforce it.
Decision rule: If the agent could cause damage even with no data leakage, treat it as an identity-layer problem first. If the main harm is exposure of the wrong content, treat it as a data-layer problem first. Many mature deployments need both, but the first deny should sit where the risk is actually created.
Common mistake: Teams often assume data labeling is enough because the policy reads cleanly in a catalog or DLP tool. That is a weak pattern when the agent has tool access, because the dangerous step is the action itself, not only the content it may later touch.
Practitioner takeaway: Put the deny where the risk becomes irreversible. Identity should decide whether the agent may act, while data should decide how far an approved action may go and what it may reveal.
Related resources from NHI Mgmt Group
- How do security teams decide whether an AI agent should keep access to regulated data?
- How do software teams decide whether to treat AI agent and MCP-layer threats as an AppSec issue or an identity issue?
- How should security teams decide whether an AI agent gets human or non-human identity?
- How do identity teams decide whether an AI agent needs a separate governance model?