Agent capability should mirror user scope through intersection rules

At a glance

What this is: This is a governance analysis of agent authorization that says effective capability should equal the overlap of agent and user permissions, not the union of both.

Why it matters: It matters because identity teams building AI assistants and delegated workflows need an enforcement model that prevents one shared integration identity from silently amplifying every user’s reach.

Context

The security gap is not whether an agent can call tools, but whether its reach is bounded by the acting user’s permissions as well as its own. When those two permission sets are not both enforced, the system can quietly turn delegated access into broad shared access, which is a governance failure rather than a model problem.

This is a familiar identity pattern in a new wrapper: authorization should narrow capability at the moment of action, not merely describe what the integration can do in isolation. The article’s core point is that the rule already exists in cloud IAM and OAuth patterns, but many agent designs still skip the second principal entirely.

Key questions

Q: What breaks when AI agents rely on shared service accounts or API keys?

A: Shared credentials hide which actor actually performed the action, make revocation coarse, and blur accountability across humans and machines. They also let multiple agents inherit the same authority, which increases blast radius and makes incident investigation much harder when something goes wrong.

Q: Why do delegated agent permissions need deny-first evaluation?

A: Because deny-first evaluation is what lets security teams subtract capability reliably when multiple teams manage different parts of the policy stack. If allow rules run first, stale or overly broad grants can still win, and the agent keeps more reach than intended. Deny precedence makes delegated access easier to constrain without redesigning every positive grant.

Q: How should security teams test whether an agent is enforcing least privilege correctly?

A: Run two negative tests: give the agent a scope the user does not have, and give the user a scope the agent does not have. Both calls should fail. If either direction succeeds, the system is not enforcing intersection, and you have found a privilege expansion path rather than a least-privilege control.

Q: What is the difference between a bounded agent and a shared integration identity?

A: A bounded agent evaluates the user and the agent together, so the final permission set is the overlap of both. A shared integration identity evaluates only the integration, which means the acting user disappears from the control plane. The first model preserves delegation boundaries; the second silently pools access across users.

Technical breakdown

Why intersection, not union, is the correct authorization model

Intersection means the final action set is the overlap of two independent grants: what the agent is permitted to do and what the acting user is permitted to do. If widening either side alone increases the result, the system has not implemented intersection. That matters because a delegated system should never gain new reach simply because one side of the delegation chain changed. In practice, this is the same logic behind session policies, permissions boundaries, and on-behalf-of flows: the middle tier can constrain, but it should not create extra authority. The authorization decision has to be re-evaluated at request time, not inferred from a static tool list.

Practical implication: Bind enforcement to the outbound request and fail closed when either principal lacks the needed scope.

Why shared service accounts create a union failure

A shared service account collapses the two-principal model into one credential, so the acting user never participates in the authorization check. Once that happens, the agent can only compare a request against its own configuration, and the result becomes whatever the integration was granted during setup. That is why these systems often end up with excessive scopes, especially when teams give the integration broad access to make onboarding easier. The failure is structural: there is no second permission set to intersect with, so there is no way to narrow the result to the user’s actual reach. Audit logs then show a legitimate integration succeeding, which makes the leak harder to notice. Read the Ultimate Guide to NHIs: Key Challenges and Risks.

Practical implication: Treat shared integration identities as a design smell and require dual-principal evaluation before tool execution.

Why deny-first evaluation matters in delegated access

Intersection is not only about allowing less. It also depends on deny rules being evaluated before allow rules, so that capability can be removed without rewriting every positive grant. That ordering is important when different teams manage different parts of the policy stack, because it gives security teams a reliable way to subtract privilege from an agent. Without deny-first evaluation, the system becomes brittle and overly dependent on every grant staying perfectly aligned. The article shows this in cloud IAM and in MCP-style proxy flows, where per-client consent prevents a middle tier from spending its own authority on behalf of the wrong caller. Deny-first logic is what keeps delegation from becoming accidental privilege expansion.

Practical implication: Place explicit-deny controls ahead of allow decisions wherever an agent mediates access across users.

Threat narrative

Attacker objective: The attacker’s objective is to induce the agent or proxy to reveal or perform actions that the caller should not be able to reach directly.

1. Entry occurs when a shared integration or proxy credential is granted broad access that exceeds any single user’s intended reach.
2. Privilege expansion follows when the agent executes requests using only its own authority, ignoring the acting user’s narrower scope.
3. Impact appears as successful reads or actions that return sensitive data across tenant, team, or role boundaries without producing an error.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Intersection is the minimum viable authorization rule for delegated agents: if a change to the agent’s grant alone can increase effective capability, the system is not enforcing delegation, it is expanding privilege. That is the right baseline for AI assistants, workflow bots, and other mediated access paths because the acting user must remain part of the decision. The implication is simple: the authority boundary belongs at the overlap, not inside the tool catalog.

Shared service accounts are an identity anti-pattern, not a convenience: they erase the second principal and convert per-user intent into a pooled capability set. That is why these systems routinely drift into overbroad access even when the front end looks personalised. In governance terms, the risk is not just excess privilege, but the loss of attribution for whose access was actually used.

Deny-first logic is the control that makes intersection real: without a way to subtract authority before allows are evaluated, delegated access stays vulnerable to policy drift and accidental expansion. Cloud IAM platforms already encode this lesson, and agent architectures should copy the pattern rather than inventing a softer version. Practitioners should treat deny precedence as a required design property, not an implementation preference.

Permission models for autonomous systems must separate reach from initiative: the agent can decide what to attempt, but it must not decide the size of its own authority. That distinction matters because a probabilistic or tool-using system can still be built on a static identity model, yet still fail if the runtime check does not bind the caller’s permissions into the final decision. The governance question is whether the system can prove the overlap before execution, not whether it can list tools.

Read next: Cloud Workload Identity Guide

What this signals

Identity teams should treat agent authorization as a request-time control, not a provisioning-time label: the real boundary is whether the system can prove the overlap before it sends a tool call. If that proof happens only in the model prompt or in a static tool list, the control is advisory rather than enforced.

As more organisations deploy assistants into CRM, ERP, and collaboration systems, the governance question shifts from 'can the agent act?' to 'whose permission is being spent when it acts?'. The strongest programmes will make the acting user visible in every decision path and treat any hidden pooled access as an exception that needs redesign.

For practitioners

• Test both sides of the permission overlap Grant the agent a permission the user lacks, then grant the user a permission the agent lacks, and confirm both requests are denied before any tool call is made.
• Move enforcement to request assembly Apply the authorization check when the outbound request is built, not when the model chooses a tool, so the model cannot bypass the final decision point.
• Remove pooled integration authority Replace shared service-account patterns with per-user or per-session delegation so the acting user remains visible in the authorization path.
• Encode deny precedence in policy design Use explicit deny rules to remove capability from delegated workflows without waiting for every positive grant to be rewritten across systems.

Key takeaways

• The article’s core finding is that delegated agent access should be the intersection of agent and user permissions, not the union of whatever the integration can reach.
• Shared service accounts are the most obvious failure mode because they erase the second principal and make overbroad access look like normal automation.
• Practitioners should test both directions of the permission overlap and move enforcement to the request boundary, where the final outbound action is assembled.

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · AI Agent Authorisation Guide · Ultimate Guide to NHIs: Standards · Multi-Cloud Identity Guide

Key terms

• Authorization intersection: An authorization model in which the final permission set is the overlap of two separate grants, typically the acting user and the delegated agent. It prevents either principal from expanding capability on its own and is the safest baseline for mediated access paths.
• Generic Service Account: A generic service account is a shared non-human identity used by applications, scripts, or automated jobs in cloud environments. It is created for convenience, but it often lacks clear human ownership and individual accountability. If poorly governed, it can retain broad access and become difficult to audit or contain.
• Deny-first evaluation: An authorization sequence in which explicit deny rules are checked before allow rules. This ordering lets security teams remove capability cleanly, which is especially important when multiple policy layers and delegated identities are involved.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.