Notifications
Clear all
Topic starter
10/06/2026 11:21 pm
TL;DR: AI agents need access to databases, APIs, SaaS tools, and internal infrastructure, but traditional IAM does not govern shared credentials, secrets, and service-level access paths well enough, according to 1Password. The decisive issue is not connectivity but whether access is centrally managed at runtime rather than embedded in code or configuration.
NHIMG editorial — based on content published by 1Password: secure AI agent access with Natoma and 1Password
Questions worth separating out
Q: How should security teams govern AI agent credentials in enterprise workflows?
A: Security teams should store agent credentials centrally, retrieve them at runtime, and enforce policy at the point where the agent interacts with each system.
Q: Why do AI agents create more risk than normal service accounts?
A: AI agents can reuse the same credential across multiple tools and workflows, which makes the access path harder to scope and revoke than a typical service account session.
Q: What breaks when credentials are embedded in agent configurations?
A: Embedded credentials break point-of-use governance.
Practitioner guidance
- Move agent credentials into centralized secret storage Keep shared passwords, API keys, and tokens out of code and configuration files, and require runtime retrieval from a controlled vault before the agent can use them.
- Broaden governance beyond initial login Map where an agent can reuse the same secret across workflows, downstream tools, and service-level access paths, then define revocation and audit requirements for each path.
- Apply policy at the agent interaction point Set read-only, write-blocking, query-rate, and scope-by-group rules where the agent actually reaches the target system, rather than relying on static entitlement design alone.
What's in the full article
1Password's full article covers the operational detail this post intentionally leaves for the source:
- How Natoma brokers agent access at runtime before the target system interaction occurs.
- How 1Password keeps credentials centrally managed while the agent retrieves only the necessary secret reference.
- How policy controls can restrict read-only access, write operations, query rates, and scope by agent or user group.
- How the combined approach is positioned for enterprise workflow integration rather than generic secret storage.
👉 Read 1Password's analysis of secure AI agent access and runtime secrets control →
AI agent credentials and runtime access governance: what changes now?
Explore further
12/06/2026 5:15 am
AI agent access exposes the failure of credential-centric IAM. Traditional access models assume the sensitive identity event happens at login, then the rest is a governed session. That assumption fails when the actor is an agent that retrieves and reuses secrets at runtime across multiple tools, systems, and workflows. The implication is that credential governance now has to account for continuous use, propagation, and revocation, not just initial authentication.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to Guide to the Secret Sprawl Challenge.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: How do organisations know if agent access governance is working?
A: Governance is working if teams can answer three questions quickly: which agent used which credential, where that credential was used, and whether policy constrained the interaction consistently across systems. If those answers require manual reconstruction, the programme still depends too heavily on scattered secrets and weak runtime visibility.
👉 Read our full editorial: AI agent credentials need runtime governance, not embedded secrets
