AI agent tool access needs scoped tokens and human step-up

At a glance

What this is: This is a playbook for governing AI agent tool access, with the key finding that authorization controls must replace trust in model alignment.

Why it matters: It matters because IAM teams now have to govern agent identities, tool scopes, and step-up paths alongside human users and non-human workloads.

👉 Read Scramble ID's playbook on AI agent tool access and step-up controls

Context

AI agent tool access is an authorisation problem, not an alignment problem. When an agent can call tools, the control question becomes which identity can invoke which action, under what scope, with what proof, and whether the action can be reversed.

That changes identity governance for both non-human and human programmes. Agents need their own identity, their own audit trail, and their own approval boundary, because borrowing human credentials destroys revocation, accountability, and blast-radius control.

Key questions

Q: How should security teams prevent AI agents from doing too much in production?

A: Security teams should give agents the smallest possible tool scopes, bind tokens to the sender, and keep token lifetimes short. High-risk actions need human proof before execution, and irreversible actions should require dual control. If a tool cannot be safely replayed, delayed, or audited, it should not be enabled for autonomous use.

Q: Why do AI agents need their own identity instead of borrowed human credentials?

A: AI agents need their own identity because borrowed human credentials destroy auditability, make revocation imprecise, and expand blast radius. Separate identities let teams scope access to the agent’s task, revoke it without affecting the human user, and trace every action back to the actual executor. That separation is foundational for governance.

Q: What breaks when tool access is treated like an alignment problem instead of an authorization problem?

A: What breaks is control. A well-aligned model can still misuse a tool if the runtime allows broad scopes, replayable tokens, or weak approval boundaries. Authorization design decides which actions are possible, who can approve them, and whether they can be reversed. Alignment does not replace those controls.

Q: Who should approve high-risk agent actions such as password resets or payout changes?

A: High-risk agent actions should be approved by the human group that owns the business process, not by the agent itself or by a general operator pool. The approval should be tied to the specific action, the affected identity or account, and the expected outcome. For money movement or privilege change, dual control is often appropriate.

Technical breakdown

Scoped, short-lived tokens for agent tool calls

Tool calls should use short-lived access tokens bound to the agent identity and the target audience. Sender-constrained proof, such as mTLS or DPoP, changes token theft from a credential compromise into a blocked replay attempt. That matters because bearer tokens are too easy to reuse once copied from logs, memory, or intercepted traffic. In practice, the token must carry the minimum scope for the specific tool action and expire fast enough that session reuse is not a viable attack path.

Practical implication: bind every agent token to the caller, the audience, and a short TTL before allowing tool execution.

Human proof and dual control for irreversible actions

Irreversible tool actions sit in a different control class from read-only or reversible writes. A password reset, payout change, or privilege change needs step-up proof and, in some cases, dual approval because the action changes the trust state of the identity system itself. The playbook separates first write, reversible write, and irreversible change so that the approval burden rises with blast radius. That is a governance model, not a model-safety model.

Practical implication: require explicit human verification and dual control before any agent can execute a high-impact action.

MCP server identity and delegated execution

An MCP server is itself a non-human identity, and it should not impersonate the agent behind the scenes. The agent authenticates to the MCP server, the server authenticates to downstream APIs with its own credentials, and the approval context travels separately in a structured request field. This separation preserves auditability and keeps the server from becoming a hidden proxy for uncontrolled privilege expansion. It also lets each tool in the catalog be classified independently by risk ring.

Practical implication: give the agent and the MCP server separate identities, separate scopes, and separate logs.

Threat narrative

Attacker objective: The objective is to turn a tool-using agent into a privileged execution path that performs actions the operator did not intend and cannot easily reverse.

1. Entry occurs when an attacker or malicious instruction path reaches an agent that can call tools through permissive scopes or replayable bearer tokens.
2. Escalation happens when the agent is induced to misuse a higher-risk tool, or when a token is reused beyond the intended sender, audience, or approval boundary.
3. Impact follows when an irreversible action, such as data export, password reset, or payout change, is executed without sufficient proof or dual control.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool access for agents is an identity governance problem disguised as an AI problem. The article is right to frame alignment as insufficient, because the control failure sits at the authorization boundary, not in model intent. Once an agent can select tools and execute actions, IAM, PAM, and audit design become the real security layer. Practitioners should treat agent tool access as governed identity, not conversational behaviour.

Scoped, sender-bound access is the minimum viable trust model for agentic execution. Bearer-style access assumes the token can move safely between contexts, but tool-using agents create far more replay and leakage opportunities than human workflows. Binding tokens to the agent identity and the target server restores some of the control lost when the model is allowed to act at runtime. The practitioner conclusion is simple: if the token can be replayed, the trust model is already broken.

Human approval is a control boundary, not a user-experience step. The playbook’s step-up and dual-control model recognises that some actions alter the identity system itself, not just the data it protects. That is why password resets, payout changes, and privilege changes cannot be treated like ordinary writes. Organisations that collapse approval into a formality will find the agent becomes the fastest path around governance.

Separate identities for agents and MCP servers prevent hidden delegation chains. When the server reuses or impersonates the agent, accountability becomes ambiguous and blast radius becomes impossible to contain. Independent identities let teams classify tools, scope access, and audit execution at each hop. Practitioners should design for traceable delegation, not convenient impersonation.

Four-ring classification gives security teams a repeatable way to decide where agent autonomy stops. The named concept here is the control ring, which ties risk to reversibility, side effects, and authentication impact rather than to model sophistication. That framing is more durable than debating whether an agent is clever enough to be trusted. The operational conclusion is to classify tools first, then attach the minimum control that matches the ring.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and those incidents are 13% more likely to be categorised as critical than code-based leaks.
• The operational next step is to tighten lifecycle and revocation discipline, using Ultimate Guide to NHIs to connect token exposure, offboarding, and access review.

What this signals

Sender-bound agent tokens are becoming the practical floor for tool governance. Once agents can browse, query, write, or hand off across tools, bearer-style assumptions create avoidable replay risk. Security teams should expect token binding, per-server scopes, and stronger approval artifacts to move from specialist design choices into baseline requirements, especially where OWASP Agentic AI Top 10 controls are being adopted.

Control rings create a useful operating model for separating reversible automation from irreversible authority. The distinction matters because many teams are still granting the same approval path to read-only lookups, reversible writes, and privilege-changing actions. A ring-based model gives IAM and PAM teams a common language for classification, review, and exception handling.

64% of valid secrets leaked in 2022 are still valid and exploitable today, according to our secrets sprawl research, which is why agent governance must include revocation as a design requirement, not an afterthought. If the token or credential can outlive the task, the agent inherits the exposure window.

For practitioners

• Bind every agent token to its sender and audience Use short-lived tokens with PoP controls so intercepted credentials cannot be replayed against a different tool or server. Separate the agent identity from downstream service credentials and keep TTLs tight enough to limit reuse.
• Classify tools by blast radius before enabling them Score each tool on reversibility, side effects, authentication impact, and data sensitivity, then assign a ring before any production rollout. Treat read-only, reversible write, and irreversible change as different authorization classes.
• Require human proof for irreversible actions Force step-up verification for high-risk actions such as password resets, payout changes, and privilege modifications. Add dual approval where the action changes money movement, access state, or other hard-to-reverse outcomes.
• Log agent, server, scope, and outcome on every call Capture the agent id, key id, token id, tool name, action, resource, result, and correlation ids so an auditor can reconstruct the chain end to end. Keep the log format consistent across the agent runtime and the MCP server.
• Validate MCP tool descriptions as untrusted input Register MCP servers through allowlists, re-check their tool catalogs on refresh, and reject tool descriptions that deviate from approved schemas. Do not let prompt text inside a tool catalog become an instruction channel.

Key takeaways

• AI agent tool access fails when teams rely on model alignment instead of identity controls, token binding, and explicit authorization.
• The real security boundary is the tool action, especially when that action can reset credentials, move money, or change privileges.
• Practitioners should classify tools by ring, separate agent and server identities, and require human proof before any irreversible step.

Key terms

• Agent Identity: The unique identity assigned to an AI agent so it can authenticate and be governed as the executor of actions. In practice, it separates the agent from the human operator, which preserves auditability, enables targeted revocation, and prevents privilege from hiding behind a borrowed account.
• Sender-Constrained Token: An access token that is cryptographically bound to the client that obtained it, so it cannot be replayed by another party. For AI agents, this reduces the impact of token leakage and forces tool access to remain tied to the authenticated runtime that requested it.
• Step-Up Verification: An additional proof requirement triggered before a higher-risk action can execute. For agentic workflows, step-up is used when the action changes identity state, moves money, or creates hard-to-reverse consequences, ensuring that the agent cannot cross high-impact boundaries on its own.
• Control Ring: A risk classification model that maps a tool to the minimum control needed for safe use. In agentic systems, ring assignment depends on reversibility, authentication impact, data sensitivity, and external side effects, rather than on how sophisticated the model appears.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: AI Agent Tool-Access Playbook. Read the original.