Security teams should separate approval from disclosure. The agent can request access, but the secret should stay in a trusted vault and be injected only into the target page at the moment of use. Scope access to a single task or session, require user approval, and remove standing access so the model never sees passwords or one-time codes.
Why This Matters for Security Teams
Browser-based AI agents create a dangerous trust boundary because the model can decide what to do, but it should not be allowed to see the credentials that make the action possible. If passwords, session cookies, or one-time codes are copied into prompts or tool context, they become part of the model’s reachable state and can be leaked through logs, retries, or unintended tool calls. Current guidance increasingly treats this as an identity and workflow problem, not just a secrets storage problem.
NHIMG research on The State of Secrets in AppSec shows how persistent secrets exposure remains a major operational issue, with remediation delays and fragmented control patterns that weaken assurance. For agentic browser automation, the same lesson applies faster because an autonomous workflow can reuse access, chain actions, and expose sensitive material in ways a human user would not. OWASP’s OWASP Agentic AI Top 10 and NIST’s AI Risk Management Framework both point toward runtime controls, bounded authority, and explicit oversight rather than blanket trust.
In practice, many security teams encounter credential leakage only after a browser agent has already copied, autofilled, or relayed the secret into places they never intended.
How It Works in Practice
The safest pattern is separation of approval from disclosure. The agent may request access, but a trusted control plane or vault service should retain the credential and release it only at the moment of use, into the target page or session, not into the model prompt or memory. That means the model learns the task outcome, not the secret itself.
For browser-based agents, this usually combines four controls:
- Just-in-time credential issuance with a narrow TTL, tied to one task or one browser session.
- Workload identity for the agent runtime, so the system can verify what is acting before granting anything.
- Policy evaluation at request time, using task context, destination, user approval, and risk signals.
- Automatic revocation and cleanup after the interaction completes or times out.
This is consistent with the direction described in NHIMG’s Guide to the Secret Sprawl Challenge and the broader NHI guidance around dynamic secrets in the Ultimate Guide to NHIs. It also aligns with SPIFFE-style workload identity principles and the runtime authorization emphasis in the OWASP Non-Human Identity Top 10. The operational goal is simple: the agent can act, but it never possesses reusable secrets outside the minimum execution window.
These controls tend to break down when the browser session is long-lived, shared across tasks, or coupled to legacy apps that cannot cleanly separate page automation from credential handling.
Common Variations and Edge Cases
Tighter browser credential controls often increase orchestration overhead, requiring organisations to balance usability against session friction and application compatibility.
Some environments can safely use a delegated session token instead of a human password, especially when the target application supports short-lived, scoped access. Other environments still require a real credential at the last mile, but even then the model should only request the action while the vault or browser broker performs the injection. Best practice is evolving here, and there is no universal standard for every browser automation stack.
Edge cases matter. Shared kiosks, multi-tab workflows, and sites that rely on MFA challenge loops can force additional safeguards such as user re-approval, per-step transaction binding, or hard stops on navigation outside the approved domain. The security team should also treat clipboard automation, autofill extensions, and DOM scraping as disclosure paths, not just convenience features. NHIMG’s Moltbook AI agent keys breach and the research on LLMjacking show how quickly compromised non-human credentials can be abused once they leave controlled handling. For implementation claims, the runtime policy model is reinforced by the CSA MAESTRO agentic AI threat modeling framework, while the identity proofing side is consistent with NIST SP 800-63 Digital Identity Guidelines.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Focuses on limiting agent tool abuse and secret exposure in autonomous workflows. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses short-lived, scoped credential handling for non-human identities. |
| CSA MAESTRO | Covers threat modeling for agentic systems with delegated access and browser actions. | |
| NIST AI RMF | Supports governance for context-aware authorization and human oversight of AI actions. | |
| NIST Zero Trust (SP 800-207) | PA-4 | Zero trust requires per-request verification rather than standing trust in the agent. |
Apply runtime risk checks and accountability controls before an agent receives credentialed access.
Related resources from NHI Mgmt Group
- How should security teams implement MCP access for AI agents in Dropbox without exposing regulated data?
- 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 govern AI agents that can access enterprise systems?
