Notifications
Clear all
Topic starter
22/06/2026 5:03 pm
TL;DR: AI agents should authenticate with short-lived, sender-bound machine credentials and request risky actions through human proof or dual control, according to Scramble ID. That model closes replay and accountability gaps that current IAM patterns leave exposed when agents can call tools, chain decisions, and act at machine speed.
NHIMG editorial — based on content published by Scramble ID: AI Agent Authentication In one sentence
Questions worth separating out
Q: How should security teams authenticate AI agents without using human credentials?
A: Security teams should give each AI agent its own non-human identity, short-lived credentials, and scoped access to specific tools.
Q: Why do AI agents create higher access risk than ordinary service accounts?
A: AI agents create higher access risk because they can choose tools, chain actions, and move across systems during a single session.
Q: What breaks when AI agent access is treated like a normal API token?
A: What breaks is accountability and replay resistance.
Practitioner guidance
- Issue separate identities for every agent workload Create one agent record per process or workload with named ownership, allowed tools, environment limits, and revocation status.
- Bind agent tokens to the sender Use short-lived JWT client assertions and sender-constrained tokens so a stolen credential cannot be replayed elsewhere.
- Classify tool calls by action risk Map each tool action to a risk tier, then require step-up approval or dual control for irreversible actions such as payouts, admin changes, and key operations.
What's in the full article
Scramble ID's full article covers the implementation detail this post intentionally leaves at the architectural level:
- Step-by-step JWT client assertion validation logic for agent authentication and replay prevention
- Sender-constrained token handling patterns for mTLS and DPoP in sensitive API calls
- Policy matrix examples showing which action classes need step-up or dual control
- Illustrative pseudocode for token endpoint and resource server validation
👉 Read Scramble ID's analysis of AI agent authentication and proof-of-possession →
AI agent authentication: are your controls ready for tool risk?
Explore further
22/06/2026 5:18 pm
AI agent authentication is becoming a governance layer, not just a login problem. Once an agent can choose tools at runtime, the question is no longer only whether it is authenticated. The real issue is whether the organisation can prove which agent acted, on which tool, under which approval boundary, and with what revocation path. That makes agent auth a combined IAM, NHI, and workflow-control problem, not a niche implementation detail. Practitioners should treat it as part of identity architecture, not application glue.
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.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, showing how non-human execution environments concentrate risk.
A question worth separating out:
Q: Who should approve high-risk actions taken by AI agents?
A: High-risk actions should be approved by a human, and for some actions a second approver should be required. The approval should be tied to the action class, not to the tool or system alone. This is especially important for irreversible events such as payouts, key changes, and administrative resets, where a single agent session should never be enough.
👉 Read our full editorial: AI agent authentication needs machine identity and human proof
