Topic starter
25/10/2026 11:06 am
TL;DR: Agents gain durable authority from long-lived API keys, which Kontext says makes them hard to scope or revoke at scale. Runtime authorization has to keep policy separate from resource access so revocation, audit, and scope changes remain usable.
Editorial analysis by NHI Mgmt Group, based on content published by Kontext: “The API Key is Dead: A Blueprint for Agent Identity in the age of MCP”.
Key questions
A: Token exchange reduces risk because the agent never needs a permanent bundle of credentials or blanket permissions.
Q: How should teams govern agent access when autonomy increases?
A: Teams should govern agents as runtime principals, not as static app settings.
Q: Why do long-lived API keys create more risk for AI agents?
A: Long-lived API keys increase risk because they persist across tasks, deployments, and runtime changes.
Practitioner guidance
- Replace standing API keys with short-lived delegated tokens Move agent access to scoped OAuth flows with token expiry, explicit consent, and revocation paths instead of static secrets in config files.
- Separate the authorisation server from the MCP resource server Keep policy enforcement and token issuance outside the tool server so the server only validates tokens and serves resources.
- Model each agent as a distinct software identity Give agents their own client identity, metadata, and audit trail so permissions can be assigned, traced, and retired independently.
Bottom line: Static API keys give agents durable authority that is difficult to scope or revoke, which makes them a poor fit for scaled agent deployments.
Glossary terms: Dynamic Client Registration, Bearer Credential, Delegated Identity, Runtime Authorisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
Static secrets are not an agent governance model: API keys turn every connected agent into a permanent bearer of authority, which is the opposite of how identity should behave in a delegated runtime. The article correctly shows that the problem is not just leakage, but persistence without context. That persistence defeats revocation discipline and makes agent access impossible to reason about at scale. Practitioners should treat long-lived keys as an architectural warning sign, not a convenience.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
Q: What should security teams monitor after moving agents to delegated identity?
A: Security teams should monitor token issuance, refresh, scope changes, consent grants, revocation events, and unusual tool usage. Those signals show whether delegated identity is still aligned to the intended task, or whether the agent has accumulated access that no longer matches its original authorisation.
👉 Read our full editorial: Static API keys fail as agent identity shifts to runtime decisions
This post was modified 7 days ago by NHI Mgmt Group