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.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “Natoma and 1Password help enterprises scale AI securely with governed agent access”.
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
Key questions
Q: What breaks when credentials are embedded in agent configurations?
A: Embedded credentials break point-of-use governance.
Q: Why do monolithic AI agents create higher credential risk?
A: Monolithic agents combine reasoning, execution and credential storage in one process, so a compromise in one part can expose the rest.
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Practitioner guidance
- Centralise AI agent secrets Keep passwords, API keys, and tokens in a controlled vault rather than embedding them in code, configuration files, or internal tools.
- Broker runtime secret retrieval Require a runtime access layer to retrieve or reference credentials only when an agent needs them, so the secret is not persistently exposed to the workflow.
- Scope agent permissions by task Limit each agent to read-only access, specific tables, or constrained write actions so the credential cannot exceed the workflow it was issued for.
Bottom line: AI agent access becomes hard to govern when passwords, API keys, and tokens are embedded in code or configuration instead of being managed at runtime.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 5:15 am
Runtime governance is the real control plane for AI agent access: AI agents do not fit a login-only IAM model because their access is exercised inside workflows, not just at session start. When credentials are embedded in code or configuration, governance shifts from policy to residue. The practitioner takeaway is that control has to exist where the secret is used, not where the agent was deployed.
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 teams do when an AI agent credential is no longer needed?
A: Revoke the secret at the source and remove any downstream references that allow the agent to keep using it. If the same credential remains valid across multiple tools or workflows, the access model has turned into secret sprawl and should be redesigned.
👉 Read our full editorial: AI agent credentials need runtime governance, not embedded secrets
This post was modified 2 days ago by NHI Mgmt Group