Notifications
Clear all
Topic starter
22/06/2026 5:03 pm
TL;DR: AI agents that call tools need scoped, short-lived, sender-bound tokens, with human step-up and dual control for irreversible actions, according to Scramble ID. Alignment is not an access control, so auditability, blast-radius control, and replay resistance have to be designed into the tool boundary.
NHIMG editorial — based on content published by Scramble ID: AI Agent Tool-Access Playbook
Questions worth separating out
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.
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.
A: What breaks is control.
Practitioner guidance
- 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.
- 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.
- Require human proof for irreversible actions Force step-up verification for high-risk actions such as password resets, payout changes, and privilege modifications.
What's in the full article
Scramble ID's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step control tables for read, write, and irreversible agent actions.
- Sample policy-as-code structure for classifying agent tools by risk ring.
- Detailed logging fields for audits, correlation, and incident reconstruction.
- MCP-specific guidance on server identity, tool registration, and cross-server orchestration.
👉 Read Scramble ID's playbook on AI agent tool access and step-up controls →
AI agent tool access: are your controls keeping up?
Explore further
22/06/2026 5:17 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent tool access needs scoped tokens and human step-up
