MindVault Concept: Session Handoff. The moment a different person or process takes over a session that is already signed in. When an employee hands work to an AI agent, that handoff is approved, and it still needs a record.

Picture an accounts payable analyst who asks an AI agent to reconcile last quarter's invoices. She heads into a meeting. The agent keeps working in her signed-in browser for forty minutes.

That afternoon, a vendor's bank details change.

Who made that change?

  • She did, before the meeting.
  • The agent did, as part of the job she gave it.
  • The agent did, because an instruction hidden in an email told it to.
  • Someone else did, at her unlocked desk.

The application log shows the same thing all four times: her account.

This will come up more often. Gartner predicts that by 2028, at least 15% of day-to-day work decisions will be made autonomously through agentic AI, and that 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024.

"On behalf of" and "as" are different

Identity engineers drew this line years ago. RFC 8693, the 2020 OAuth standard for token exchange, describes two ways one party can act for another.

  • Impersonation: the agent gets the person's rights and looks like the person.
  • Delegation: the agent keeps its own identity, and the token can record that delegation happened, even through a chain of several parties.

Delegation leaves a trail. Impersonation leaves the person's name on everything.

Some agents work much closer to impersonation. They drive the employee's own browser with the employee's own signed-in sessions. To the application, every click looks like her.

An old problem with a new deputy

In 1988, computer scientist Norm Hardy described a bug that has stayed useful ever since. A compiler had permission to write to its own directory. A user told it to send its debug output to a file in that same directory, which happened to be the billing file. The compiler overwrote the bills.

The code was correct. Hardy's point was that the compiler "serves two masters" and carried authority from both, with no way to tell which one a given action should use. He called it the confused deputy.

An AI agent serves two masters too: the person who gave it the task, and every page, email, and document it reads along the way. We read Hardy's paper as a reminder to ask two questions about every action: does this account have permission, and whose authority is this action using right now?

That idea has not stayed academic:

  • The Model Context Protocol, an open standard many AI agents use to connect to business tools, lists the confused deputy problem among the attacks its implementers must defend against. Its security guidance also forbids passing a person's token straight through to other services, partly because the logs would then show a different identity than the one actually acting.
  • OWASP lists excessive agency among its top risks for AI applications. Its advice: run actions in the context of the specific user with the least privilege needed, and require a human to approve high-impact actions.
  • NIST's National Cybersecurity Center of Excellence opened a concept paper for public comment in February 2026 on AI agent identity and authorization. Among its open questions: how to handle delegation for "on behalf of" scenarios, and how to bind agent actions back to human authorization.

When NIST is still asking the question, nobody should claim to have the full answer.

Four questions the record should answer

For any workflow where people hand work to agents, the evidence should answer four questions:

  1. Who handed off, and when? The person, the time, and the task.
  2. What was the agent allowed to do? Which applications, which data, which actions, and for how long.
  3. Who was operating at each moment? The person, the agent, or nobody.
  4. When did the authority end? The task finished, the time ran out, the person took control back, or someone revoked it.

That last question gets skipped the most. Permission that never ends turns into a standing credential. An agent that can still act tomorrow, under yesterday's approval, is a risk nobody signed up for.

Who is operating right now?

Operator Continuity asks whether the entity operating a session right now is the one it was issued to. With agents, the true answer is sometimes "no, it is the agent she sent." That is fine. The question becomes whether the operator right now is one of the authorized ones, working inside its grant.

Part of that answer is measurable today. MindVault measures whether interaction stays consistent with the enrolled person. A change in that pattern can help an investigator decide where to look. Agent and application records are still needed to confirm whether an agent took over and when its permission ended.

The other part is earlier work across the industry. Checking that an agent stayed inside its scope, and telling one kind of automation from another, is still maturing. As we wrote in AI Agents Need Identity Too, any vendor claiming to fully solve agent identity today is ahead of the evidence. Extending Continuous Identity Confidence to agents, as that evidence matures, is part of our vision.

What this cannot tell you

Three limits matter.

  • A well-behaved agent can follow bad instructions. Knowing the agent was operating does not tell you its instructions were legitimate. Prompt injection, covered in AI Agents and the New Attack Surface, works exactly this way.
  • Some agents never touch the desk. An agent running in the cloud with its own tokens leaves its trail in identity provider and application logs, not on the employee's computer.
  • An approval is still an approval. If the person approved a harmful action, the record will show that she did. That case belongs to training and process.

Start with one workflow

Pick one place where employees already use agents, such as expense reports, CRM updates, or research. Then write down four things:

  • the grant: who may send an agent, and for what,
  • the scope: which apps, data, and actions,
  • the end: a time limit or task limit, and
  • the approval: which steps need a person to say yes first.

Then take one question to your next tabletop exercise:

If an agent changed something in this workflow last Tuesday, could we show who sent it, what it was allowed to do, and when that permission ended?

If the answer is no, you found the gap before an attacker did.

MFA proves who logged in. MindVault measures who stayed.

Frequently asked questions

Is an agent working in an employee's session a security problem?

Not by itself. Delegation is normal work. The questions are whether it was authorized, whether it stayed in scope, and whether anyone recorded it.

Can MindVault tell when an agent took over from a person?

Not on its own. MindVault measures whether interaction stays consistent with the enrolled person, and a change can point an investigation to the right window. A pause in typing could just mean someone is reading or sitting in a meeting, so agent and application records are needed to confirm a handoff. Confirming that an agent stayed inside its grant is earlier-stage work across the industry, and we treat it as part of our vision.

Do standards cover agent delegation yet?

Partly. OAuth token exchange can record delegation, OWASP lists excessive agency as a top AI application risk, and NIST's NCCoE is collecting input on agent identity and authorization. Common practice is still forming.

Sources: Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," June 25, 2025 (gartner.com). IETF RFC 8693, OAuth 2.0 Token Exchange, January 2020 (rfc-editor.org). OWASP Top 10 for LLM Applications 2025, LLM06: Excessive Agency (genai.owasp.org). Model Context Protocol, Security Best Practices, specification version 2025-11-25 (modelcontextprotocol.io). NIST NCCoE, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, draft concept paper, February 2026 (nist.gov).

Ideas we learned from: Norm Hardy, "The Confused Deputy (or why capabilities might have been invented)," ACM SIGOPS Operating Systems Review 22(4), October 1988 (mit.edu copy).