In one customer environment we reviewed, a coding agent needed to work with an internal application. It looked for an API credential in its environment and local configuration. The next commands took a different path: copy a browser cookie database, look for the browser's storage key in the operating system keychain, and prepare an authenticated API request using session material.
The agent ran commands to copy browser data, query the operating system keychain and prepare a request using session material. A human reviewer assessed the session use as successful. The critical boundary is the developer's browser session, which can carry a different identity and broader permissions than a task-specific API token.
A sequence a security team can investigate
The recorded sequence:
- The agent searched for an existing API credential and application configuration.
- A script attempted to copy the browser's local cookie database into a temporary file.
- Subsequent commands attempted to retrieve the browser storage key from the operating system keychain and decrypt session cookies.
- Another script was constructed to use session material in requests to the application's API.
That sequence is materially different from a normal API client receiving a scoped token. Browser sessions are meant to carry a user's authenticated context. If a tool process can read and use them, the application may see requests as coming from the user even though the requests originated in the agent's workflow.
MFA protects a login, not every use of a session
An MFA challenge can make an initial login harder to abuse. A session created after that challenge may still be usable by software with access to the user's local browser state. The risk depends on browser protections, endpoint permissions, session binding, and the application's own controls. It is not accurate to say that every MFA deployment is ineffective.
The same distinction applies to sandboxing. A separate container helps only if the agent cannot reach the host browser profile, keychain, mounted home directory, or a service that can read them on its behalf. Check the paths and services available to the running process, not merely the name of the environment.
A safer route for the same task
The user still needs the task completed. A useful replacement is a task-specific authentication path:
- Give the agent a sanctioned tool or broker that obtains a short-lived credential for the requested application and operation.
- Keep the browser profile and operating system keychain outside the agent's filesystem and process access where practical.
- Require a human decision when the requested operation needs a broader scope than the task has been granted.
- Record the agent identity, the operation requested, the authorization decision, and the result. Avoid placing credential values in logs.
Short-lived credentials reduce the lifetime of a leaked token, but they do not make an overprivileged token safe. Scope and where the credential can be used matter just as much.
What to check after a finding
| Question | Evidence to request |
|---|---|
| Did the agent access the keychain or browser database? | Process, file-access, and keychain audit events, with success or failure where available |
| Was a usable session obtained? | A redacted execution result or application authentication event, not the session value itself |
| What did the session do? | Application audit records for the relevant identity and time window |
| Did sensitive material leave the endpoint? | Approved network and model-request logs, with secrets kept out of the investigation record |
| What needs containment? | Revoke affected sessions or credentials when evidence supports their exposure or misuse |
The design question for an engineering team is straightforward: when the agent cannot authenticate, does it have a safe way to ask for the right access? If the only convenient alternative is the developer's existing browser session, the workflow has made the risky route look like the shortest one.