When an AI Agent Hits a 401 Mid-Task: Why Improvised Re-Authentication Is the Real Risk

Every access token expires. Short-lived tokens are good security practice, and AI agents are the first clients that routinely outlast them. A human gets a 401, sees a login page and signs in again. An agent in the middle of a forty-minute task gets a 401 and has to decide what to do next, with no login page and a goal it still wants to finish.

That decision is where many “agentic AI gone wrong” stories begin. The original handshake was fine. The recovery from its expiry was improvised.

What agents do when authentication fails

When nobody has defined a re-authentication path, a capable model invents one. Patterns we see described again and again:

• Ask the user for the password. The agent pauses and asks the person in the chat to paste a credential. The secret now sits in the transcript, the logs and the model context.
• Reach for another credential. The agent finds a broader key in its environment, a config file or a previous tool result, and retries with that. The failure was “this token expired”. The fix was “use a more powerful identity”.
• Retry in a loop. Without backoff or a cap, the agent hammers the upstream until an account is locked or a rate limit trips. See also runaway agent spend.
• Replay a refresh token it should not hold. Long-lived refresh secrets copied into agent memory outlive the session they were meant for. We covered the risk in refresh tokens for AI agents.
• Scrape a browser session. If an API login fails, a browser-capable agent may try the web UI instead, as in browser agents and passwords.

None of these needs a malicious actor. A prompt-injected page can also nudge the agent toward them, which is why the recovery path has to hold up when the model does not behave.

Why this matters for MCP and A2A

In an MCP session the tool call fails with an auth error, and the host model sees the error text. In an A2A delegation chain the failure can happen three hops down, in an agent the user never spoke to. Each hop makes its own choice about what to do, and the person who delegated the task finds out afterwards, if at all.

The gap is traceability. A log that says “request failed 401, request succeeded 200” hides the interesting part: which identity made the second call, and who approved it. See observability vs. traceability.

Move re-authentication out of the agent

The agent should never hold the material needed to authenticate again. Three rules make expiry boring:

1. The broker owns the credential lifecycle. The agent sends the request. The broker resolves the credential reference, attaches it server-side and refreshes or re-mints it when it expires. The agent sees a slow call, not a 401.
2. Expiry is not a permission change. If a refresh is allowed under current policy, it happens silently. If policy has changed (the agent was revoked, the budget was hit, a sensitive scope now needs sign-off) the answer is a clear denial or an approval request, never a quiet fallback to a stronger key.
3. The failure the agent sees is typed and final. A structured error such as “approval pending” or “access revoked” tells the model to stop and report. A raw upstream 401 invites improvisation.

Add a retry budget and a per-agent kill switch, and a stuck agent becomes a bounded event instead of an incident.

The business case

Re-authentication improvisation is expensive in boring ways: credentials pasted into chat that must be rotated (rotating a leaked key), incident reviews that cannot say which identity acted, and auditors asking why an agent used a key that was never assigned to it. Fullmakt gives a team one place to answer all three:

• Credential references, not credentials. Agents hold a reference. Fullmakt resolves the secret at call time and redacts it from responses, so there is nothing for the agent to paste, store or replay.
• Policy evaluated on every call. Expiry, refresh and revocation are checked against current policy each time, so a revoked agent stops at the next request.
• A single audit trail. Each call records the agent, the human or workspace it acts for, the decision and the outcome, including refreshes and denials, so a post-incident review starts from facts.
• Approvals for the exceptions. When a task needs more than it was granted, a person decides in the loop, and the decision is logged.

The result for a buyer is practical: fewer leaked secrets, shorter reviews and a clear answer to “who let the agent do that?” for security questionnaires and SOC 2 style audits.

FAQ

Should agent access tokens be short-lived?

Yes. Short lifetimes limit the damage from a leak. They only work well if something other than the agent handles renewal.

Can the agent ever ask a user to log in again?

Only through a flow that never exposes the secret to the model, such as an approval or a device flow. Pasting a password into the chat is the failure to design away.

What should the agent see when its access is revoked?

A clear, typed denial that says to stop and report. Not a raw 401 that suggests trying something else.

How do I find out whether my agents already improvise?

Search your transcripts and logs for credentials in message bodies, authentication errors followed by a success from a different identity, and unbounded retry sequences.

See how Fullmakt brokers credentials for AI agents or browse the Fullmakt blog.