How should security teams let AI agents complete logged-in tasks without exposing passwords or one-time passcodes?

Why This Matters for Security Teams

Letting an AI agent finish a logged-in task without revealing passwords or one-time passcodes is not just a convenience problem. It is an identity control problem. Once a secret enters model context, browser automation, or a shared task queue, it can be copied, replayed, or exposed in logs. That risk is amplified for agents because they chain tools, retry actions, and operate faster than a human can monitor. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime controls instead of static trust.

NHIMG research shows why this matters operationally: in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, exposed AWS credentials were attempted within an average of 17 minutes. That pace leaves very little room for manual remediation if an agent or workflow leaks a secret. In practice, many security teams encounter credential abuse only after an automated task has already reused a token or session in ways nobody intended, rather than through intentional testing.

How It Works in Practice

The safest pattern is to treat the human as the approver and the agent as the executor, while keeping the secret outside the agent’s reasoning space. The agent requests the task, the system checks policy, and the credential is injected only at the point of use, typically into the browser session, desktop session, or task runner. The agent never needs the password or OTP value in plaintext, and the session should expire as soon as the task is complete or abandoned.

This is where runtime identity and ephemeral privilege matter. Instead of long-lived secrets, teams should prefer short-lived session grants, scoped browser cookies, or delegated tokens with tight TTLs. For workloads that need cryptographic proof of identity, workload identity patterns such as SPIFFE or OIDC-based attestation are a better primitive than shared credentials. The goal is to prove what the agent is allowed to do at the moment of action, not to hand it a reusable secret. The broader direction is consistent with the OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, which both emphasise runtime risk over static access lists.

• Use just-in-time access grants that expire after the current task, not after a fixed administrative window.
• Inject secrets directly into the execution layer, never into prompts, transcripts, or chat history.
• Bind approvals to a specific task, site, action, and time window so the credential cannot be repurposed.
• Clear injected values and revoke the session if the task fails, stalls, or changes scope.

These controls tend to break down when the same browser profile, session store, or automation runner is reused across multiple high-value workflows because the boundary between one approved action and the next becomes unclear.

Common Variations and Edge Cases

Tighter secret handling often increases orchestration overhead, requiring organisations to balance user friction against reduced replay risk. That tradeoff is real, especially when the logged-in task spans multiple systems or needs human-in-the-loop confirmation at several steps. Guidance is still evolving on the best way to combine OTP handling, delegated browser control, and agent memory isolation, so current practice should be treated as design guidance rather than universal standard.

For some environments, the right answer is not to pass the OTP at all. If an application supports phishing-resistant authentication, step-up approval, or device-bound sessions, those options are usually stronger than trying to feed a one-time code into an agentic workflow. For others, the safest pattern is to split responsibility: the human completes the authentication challenge, then the agent uses only the resulting ephemeral session. This reduces exposure while preserving task continuity, and it aligns with the lessons in The State of Non-Human Identity Security as well as external reporting such as Anthropic's first AI-orchestrated cyber espionage campaign report. Teams should also watch for workflows where the agent can chain tools across privilege domains, because those environments can turn a narrow approval into broad lateral movement if session scope is not enforced.

When the task requires persistent access, the safer design is to remove persistent secrets from the agent path entirely and replace them with narrowly scoped delegation, revocation, and logging controls.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams use AI in secret scanning without creating new blind spots?