Notifications
Clear all
Topic starter
06/09/2026 6:20 pm
TL;DR: AI assistants and autonomous agents are pushing employees to paste passwords, API keys, and tokens into prompts when systems sit outside SSO, according to Akeyless. The real control problem is not human authentication, but removing credentials from AI workflows before runtime governance becomes necessary.
NHIMG editorial — based on content published by Akeyless: Why SSO is not enough for AI, and how to secure machine-to-machine access
By the numbers:
- 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: What should teams do first when AI tools need access to systems outside SSO?
A: The first move is to remove credentials from the workflow entirely.
Q: Why do AI assistants create a secrets-management problem even when SSO is in place?
A: SSO only covers applications that trust the identity provider.
Q: What breaks when developers paste API keys into AI-built apps?
A: The application loses clean attribution, revocation, and scope control.
Practitioner guidance
- Eliminate credentials from AI prompts Block users from pasting passwords, API keys, tokens, or SSH material into chat-based AI tools and replace that workflow with brokered access.
- Inventory every AI path outside SSO Map the legacy databases, internal APIs, SaaS apps, cloud consoles, and command-line sessions that AI assistants reach without federation.
- Issue short-lived credentials for AI tasks Use task-scoped access that expires automatically after the approved action completes instead of allowing persistent credentials to travel with the assistant.
What's in the full article
Akeyless' full article covers the operational detail this post intentionally leaves for the source:
- How SecretlessAI brokers access to enterprise systems without exposing passwords, API keys, or tokens in prompts.
- How Runtime Authority evaluates intent, live session context, and task scope before allowing an AI action.
- How the Gateway and policy layer work together to issue short-lived access for approved AI tasks.
- How existing Akeyless deployments can extend the same controls from developer workflows into AI assistants.
👉 Read Akeyless' analysis of secretless access and runtime control for AI workflows →
AI agents outside SSO: what IAM teams need to do now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
06/09/2026 6:21 pm
SSO is not failing here because it is weak. It is failing because it was designed for humans, not for software that initiates access on a person’s behalf. The article correctly separates human authentication from machine access, which is the real governance boundary in AI workflows. Once the actor is an AI assistant or agent, the old assumption that one login path covers the whole access journey no longer holds. Practitioners should stop treating AI access as a simple extension of SSO.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How should security teams govern AI assistants that can act inside IAM systems?
A: Security teams should treat AI assistants as privileged automation, not as simple chat interfaces. If an assistant can query, create, or modify identity state, it needs scoped permissions, approval gates for sensitive actions, full logging, and a rollback path. The key control question is whether the assistant can do anything a human admin could not safely delegate.
👉 Read our full editorial: AI agent access outside SSO is reviving the secrets problem
