Notifications
Clear all
Topic starter
24/06/2026 7:11 pm
TL;DR: Static API keys and service accounts were built for predictable machine behaviour, but AI agents decide at runtime, creating an authorization gap that can let broad credentials be used in ways no one explicitly approved, according to 1Kosmos. Access review processes assume privilege persists long enough to be reviewed; autonomous actors can consume and discard authority inside the execution window, leaving governance blind to the action itself.
NHIMG editorial — based on content published by 1Kosmos: Why API Keys and Service Accounts Can’t Govern AI Agents
Questions worth separating out
Q: What breaks when AI agents rely on API keys for sensitive actions?
A: API keys break at the point where a task requires runtime judgment.
Q: Why do service accounts still leave AI agent governance gaps?
A: Service accounts give you ownership and inventory, but they usually do not validate the action at execution time.
Q: How should security teams govern AI agents that can choose their own tools?
A: They should govern the action, not just the identity object.
Practitioner guidance
- Interpose policy at the tool-call boundary Evaluate each agent request before it reaches the target system.
- Separate authentication from authorisation Keep API keys and service accounts as identity proof, but require a runtime policy decision for any sensitive or destructive operation.
- Shorten the lifetime of action-scoped credentials Issue credentials only for a single approved operation where possible, and expire them immediately after use.
What's in the full article
1Kosmos's full article covers the operational detail this post intentionally leaves for the source:
- The execution-plane architecture for intercepting MCP tool calls before they reach target systems.
- How verifiable credentials are used to replace static API keys in runtime agent authentication.
- The policy-threshold logic that determines when human approval is required for higher-risk actions.
- The control-plane and lifecycle visibility problems that create ghost-agent risk when staff leave.
👉 Read 1Kosmos's analysis of why API keys and service accounts fail for AI agents →
AI agent credentials and runtime authorisation: are your controls enough?
Explore further
25/06/2026 4:22 am
Static credential governance was designed for predetermined software, not autonomous actors. API keys and service accounts assume the action set is knowable when the credential is issued. That assumption fails when the actor can alter its path at runtime, search for alternate tools, and choose execution timing without a human gate. The implication is that governance must stop treating possession as proof of authorisation.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can IAM teams tell whether agent access is actually safe?
A: Look for proof that identity is tied to the execution moment, not just the provisioning record. Safe agent access requires a control that can validate who is accountable, what action is being attempted, and whether it is approved right now. If those checks do not happen at runtime, the access model is still static.
👉 Read our full editorial: AI agent governance breaks when static credentials meet runtime action
