TL;DR: Akeyless says AI assistants and autonomous agents that reach systems outside SSO are prompting users to paste passwords, API keys, and tokens into conversations, reviving the secrets management problem in business workflows. The core issue is not human authentication but removing credentials from AI access paths before runtime governance becomes the only remaining control.
At a glance
What this is: Akeyless argues that AI access outside SSO is pushing employees to expose secrets in prompts, turning a familiar secrets management problem into an enterprise-wide AI workflow issue.
Why it matters: IAM, NHI, and PAM teams need to treat AI assistants as machine-to-machine access paths, because prompt-based credential sharing bypasses SSO and expands secret exposure beyond engineering teams.
By the numbers:
- GitGuardian’s 2026 State of Secrets Sprawl found an 81% year-over-year increase in leaked AI service credentials.
👉 Read Akeyless's analysis of AI agent access outside SSO and secretless access
Context
Single Sign-On solves human authentication for integrated applications, but it does not eliminate the need for credentials when software needs to reach systems outside the SSO boundary. That becomes an identity governance problem as soon as an AI assistant or agent is asked to act on behalf of a user.
The control gap is not theoretical. When users paste passwords, API keys, or tokens into prompts, the secret enters the AI interaction itself and can then travel into logs, history, or downstream integrations. For identity teams, that creates a machine-to-machine access path that sits outside the assumptions of conventional workforce IAM.
The article is really about secrets management under AI workflow pressure. As more employees use assistants to reach legacy databases, internal APIs, SaaS tools, and cloud services, the scope of non-human identity governance expands from developer tooling to the broader enterprise.
Key questions
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. If users are still pasting passwords or API keys into prompts, the access model is already broken. Replace that pattern with brokered, short-lived access so the AI can complete the task without ever seeing a reusable secret.
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. The moment an AI assistant reaches a legacy database, API, or cloud service outside that federation boundary, the access path falls back to secrets such as tokens, passwords, or service accounts, which must then be governed as non-human identities.
Q: What breaks when developers paste API keys into AI-built apps?
A: The application loses clean attribution, revocation, and scope control. Anyone using the app may inherit the same credential path, and the original builder often cannot explain or limit what that key can still reach later. That turns a convenience shortcut into an unmanaged access surface.
A: They should require runtime controls as soon as the AI can act, not just respond. Once an agent has tools, memory, credentials, and time, policy has to become executable through constraints on scope, permissions, approvals, and monitoring. Model alignment remains useful, but it cannot substitute for controls that enforce boundaries while the system is operating.
Technical breakdown
Why SSO stops at the human and not the machine
SSO authenticates a person to an identity provider and then federates that session into trusted applications. It does not, by itself, authenticate a software actor that needs to call a legacy database, REST API, or cloud service outside the federation boundary. Once an AI assistant must act on behalf of a user in one of those systems, the access problem shifts from user sign-in to machine authentication and credential handling. That is why the article treats this as a secrets issue, not an SSO issue. The operational danger is that the AI workflow becomes the place where the credential is supplied, stored, or replayed.
Practical implication: Map every AI workflow that exits the SSO boundary to a non-human identity control path instead of treating it as a simple extension of workforce login.
Why prompt-based credential sharing creates a secrets exposure path
A pasted password, API key, or token is not just input text. In an AI workflow it becomes part of the conversation context and may be retained, transmitted, or processed by supporting systems depending on configuration and service design. That means the secret is no longer confined to the target application where it was meant to function. The risk is structurally similar to hardcoded secrets in source code, except the leakage point is now the prompt interface. From a governance perspective, this collapses the separation between authentication and interaction, which is why the article frames secretless access as the first control step.
Practical implication: Eliminate credential entry fields from AI task flows and replace them with brokered, identity-based access.
How runtime governance changes once agents start acting autonomously
The article distinguishes between eliminating standing secrets and governing actions at runtime. That distinction matters because an AI assistant that fetches information and an autonomous agent that executes production tasks create different control requirements. At higher autonomy, access decisions cannot rely on static role assignment alone, because the question is no longer only whether the actor can connect, but whether the requested action matches intent at the moment of execution. This is where runtime authorization, session inspection, and task-scoped access become relevant. The core architectural shift is from provisioning access in advance to deciding access inside the session boundary.
Practical implication: Separate secretless connectivity from runtime authorization so that credential removal does not become a substitute for action-level control.
Threat narrative
Attacker objective: Obtain reusable access to enterprise systems by capturing credentials through AI workflows rather than through the SSO layer.
- Entry occurs when a user pastes a password, API key, or token into an AI prompt because the target system sits outside SSO.
- The secret then becomes part of the AI interaction and can be retained, replayed, or forwarded through prompt history or connected services.
- Impact follows when the credential is reused to access enterprise systems outside the user’s normal identity boundary, creating a machine-to-machine exposure path.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI access outside SSO is reviving the secrets problem rather than replacing it. The security issue is not that SSO has failed, but that AI workflows often reach systems where SSO never applied in the first place. That creates a new prompt-mediated secret handling path that looks operationally convenient but is governance-light. Identity programmes should treat this as an expansion of the secrets estate, not a new authentication model.
Secretless access is the correct first control because it removes the failure condition, not just the symptom. If users can complete AI-assisted work without exposing passwords, API keys, or tokens, the organisation reduces the chance that a secret becomes embedded in a model interaction. That is a direct NHI governance gain because the credential stops being user-supplied, user-visible, and user-reusable. Practitioners should see secretless access as the baseline control for AI-connected systems.
Runtime authority becomes necessary only after access is already being brokered safely. The article correctly separates secret elimination from action governance, which matters because many organisations rush to policy evaluation before they have removed standing credentials from AI flows. The field should not collapse these into one problem. Runtime controls address what an agent is allowed to do; secretless access addresses how it gets there in the first place.
Access review cadences are a poor fit for prompt-driven machine access unless the credential lifecycle is redesigned. A secret that is copied into an AI conversation can outlive the user’s intent, the task, and the original approval moment. That creates credential persistence in places that traditional review processes do not inspect. The practitioner conclusion is simple: review-based governance cannot compensate for secrets that should never enter the workflow.
Prompt-mediated credential use is a named governance pattern we should call credential leakage by interaction. The term captures a familiar NHI failure in a new interface. The exposure mechanism is not malicious exfiltration alone, but everyday employee behaviour when AI tools sit outside SSO. Security teams should treat that behaviour as a predictable control boundary and design around it.
From our research library:
- 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.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Credential leakage by interaction: AI tools are creating a new place where NHI secrets can leak, not because the credentials are novel, but because the interface is conversational and the controls are incomplete. Teams that still think in terms of password fatigue or developer-only secrets will miss the broader governance boundary that AI is introducing.
The practical programme response is to remove the secret from the workflow before debating runtime permissions. That means classifying AI assistants that touch external systems as machine-to-machine access paths, then deciding which ones can be made secretless and which ones require policy enforcement at execution time.
The scale signal is already visible: the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities. That gap matters because AI-driven credential exposure will outpace manual response unless the access model changes.
For practitioners
- Implement secretless AI access for non-SSO systems Route AI assistants and agents through brokered access paths that authenticate the user, apply policy, and issue only task-scoped access without exposing passwords, API keys, or tokens.
- Remove credential entry from AI workflows Eliminate prompts, forms, and local files that ask employees to paste secrets into AI conversations, especially where the target system is a legacy database, SaaS app, or internal API.
- Classify AI-connected systems as machine-to-machine access paths Treat any AI workflow that calls enterprise systems outside SSO as an NHI governance problem, with ownership, inventory, and lifecycle controls attached to the underlying credentials.
- Separate secret removal from runtime authorisation Use secretless access to prevent standing credential exposure first, then apply intent-aware policy and session controls only where AI agents are actually allowed to execute actions.
Key takeaways
- AI assistants that operate outside SSO are reviving the secrets problem by encouraging users to paste credentials into prompts.
- The exposure is not limited to developers, because any employee using AI to reach non-SSO systems can turn a secret into part of the interaction.
- Secretless access should come before runtime governance, because action controls do not fix credential leakage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Prompt-pasted credentials create the leak path this article centres on. |
| NHI-04 — Insecure Authentication | The article focuses on AI access paths that bypass the normal authentication boundary. | |
| NHI-07 — Long-Lived Secrets | The article argues for short-lived access instead of embedded or persistent credentials. | |
| Recommendation — Remove secrets from AI workflows and revoke any credential exposed through prompts or logs. Route AI access through authenticated, policy-driven brokers instead of direct credential entry. Replace standing AI credentials with short-lived, task-scoped access for every non-SSO target. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central to preventing pasted and persistent secrets. |
| Recommendation — Apply IA-5 to rotate, revoke, and scope authenticators used in AI access paths. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article describes credentials being exposed through AI prompts as the main threat path. |
| Recommendation — Map AI prompt-based secret exposure to TA0006 and prioritise detection for credential harvesting. | ||
Key terms
- Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
- Machine-to-Machine Access: Machine-to-machine access is communication where one software system or workflow reaches another without a human session in the middle. It is governed by credentials, policy, and trust boundaries, and it becomes risky when the access path is broad, poorly logged, or hard to revoke.
- Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
- Credential Leakage: Credential leakage occurs when secrets such as tokens, passwords, API keys, or certificates are exposed outside approved storage or transmission paths. In CI/CD environments, this can happen in source code, logs, build output, or environment variables. Once leaked, credentials can be reused quickly for lateral movement or unauthorized deployment access.
What's in the full article
Akeyless's 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 to the AI
- How Runtime Authority applies intent-aware policy and task-scoped control once agents begin executing actions
- How the same platform model extends from developer secrets into employee AI workflows across SaaS, APIs, and infrastructure
- How the article frames secretless access and runtime governance as separate stages of AI identity maturity
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org