Notifications
Clear all
Topic starter
12/06/2026 9:39 pm
TL;DR: Zero Trust for AI agents assumes cryptographic runtime identity, short-lived credentials, and explicit tool boundaries, but many organisations still depend on static secrets and control-by-friction, according to Hush Security’s analysis of Anthropic’s framework. Access review processes assume privilege lasts long enough to inspect; autonomous agents can acquire and discard access within a single session.
NHIMG editorial — based on content published by Hush Security: Zero Trust for AI agents is the right framework for this moment
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI agents that use tools and memory at runtime?
A: Treat AI agents as runtime identities with explicit access boundaries, not as scripts that can be trusted by design.
Q: Why do static secrets create outsized risk in AI agent environments?
A: Static secrets create outsized risk because they outlive the task, can be reused across sessions, and are easy to discover through code, pipelines, or model-assisted analysis.
Q: What breaks when access control depends on friction instead of runtime enforcement?
A: Friction-based controls break when an attacker can operate at machine speed and chain ordinary permissions into harmful outcomes.
Practitioner guidance
- Map every agent to a runtime identity Require a verifiable identity for each agent instance, workload, and service account so every access event can be attributed to a specific runtime actor.
- Replace standing secrets with task-scoped credentials Issue credentials only at the moment of access, scope them to the exact task, and expire them immediately after use to reduce the value of exposed secrets.
- Define explicit agent-to-service policies Block any connection that is not explicitly authorised at the access layer, including tool paths created by chained agent behaviour or MCP redirection.
What's in the full article
Hush Security's full article covers the implementation detail this post intentionally leaves at the strategy level:
- A tiered zero trust model for AI agents, including Foundation, Enterprise, and Advanced identity requirements.
- A runtime access-layer approach for converting observed machine-to-machine activity into explicit policy.
- A walkthrough of how SPIFFE-based workload identity supports short-lived credentials and lifecycle control.
- Operational examples of how teams can move from static secrets to just-in-time scoped access.
👉 Read Hush Security's analysis of zero trust for AI agents and runtime identity →
AI agent identity and zero trust: are your controls ready?
Explore further
12/06/2026 11:54 pm
Static secrets are the wrong trust primitive for AI agents. The article’s central problem is not merely exposure, but the fact that static credentials assume a stable identity-to-action relationship. AI agents can select tools and execute tasks at runtime, which means the secret model is already behind the behaviour it is trying to govern. The implication is that access governance has to move from stored secrets to runtime identity and task-scoped authority.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which leaves most NHI programmes unable to prove what is active or exposed.
A question worth separating out:
Q: Who is accountable when an AI agent misuses delegated access?
A: Accountability should remain with the team that granted the access and defined the policy boundaries, because the agent is operating inside a human-owned governance model. If telemetry cannot identify the specific workload or agent instance, the organisation has an attribution failure as well as an access failure.
👉 Read our full editorial: Zero trust for AI agents exposes the missing identity layer
