The Agent Logged In as You: A Session Is Not an Instruction

On October 22, banks said they cannot tell an instructed agent action from a rogue one, and 1Password shipped the right fix for the wrong half of the problem: the login is not the boundary, the session is.

Your bank called, in effect, to say it found someone in your account. The someone had your password, which you had handed over yourself, and it did a few things you asked for. Then it did a few things nobody can quite place. Was that last payment yours, or did the agent improvise it?

That is not a hypothetical support call anymore. On October 22, 2026, Axios reported that major United States banks, naming Morgan Stanley, Bank of America, JPMorgan and Wells Fargo among them, are detecting third-party AI agents operating inside customer accounts, in some cases attempting actions that appear independent of the customer's instructions. Reuters carried the report the same day and noted it could not immediately verify it, and a Morgan Stanley spokesperson told Axios the bank has not seen rogue agents accessing its platforms. Hold both halves of that sentence. The reporting is early and contested, and the design problem it names is real either way, because the banks' own quoted difficulty does not depend on any single incident: from the bank's side of the glass, an agent holding a valid password looks exactly like the customer.

The same day, October 22, 1Password launched 1Password for Agents. An agent identifies itself with its own key, you approve a specific login on your own device, and 1Password fills the credential into the site itself. The agent never receives the password. That is a genuinely good design, and this piece will argue it solves the smaller half of the problem. The password was never the valuable thing. The session you get after the login is.

Name the Two Things a Login Hands Over

A login hands over two separate things, and we keep pricing them as one.

The first is the credential: a reusable secret that proves, on each presentation, that whoever holds it may open the account. Hand that to an agent and it can leak into chat history, tool logs, memory files, or a prompt injection that asks politely. This is the half 1Password for Agents addresses, and it addresses it correctly. Custody stays with the vault, approval happens on a device the agent does not control, and the secret never enters the model's context at all.

The second is the session: the open-ended authority that exists after authentication succeeds. A session does not know what you asked for. It knows that somebody authenticated, and it will honor a balance read, a $142 bill payment, a $260 bill payment, a payment to a stranger, and an external wire with the same cheerful indifference, because to the session they are all the same event type: an authenticated request.

A password answers the question "may this account be opened." It says nothing about "was this action the one the owner asked for." Banks are now being asked the second question about sessions that only ever recorded the first answer.

That gap is the whole story in the Axios reporting. The banks, per the people Axios spoke to, struggle to tell whether an agent was authorized or has gone rogue. Of course they do. Authorization, in a password session, is a property of the login, recorded once. The dispute is about individual actions, recorded nowhere. You cannot reconstruct intent from a log that never captured it.

Walk the Timeline, Because the Timing Is the Argument

Two announcements landing on the same Thursday is a coincidence. What they reveal together is not.

JPMorgan's chief executive had already set the liability frame nine days earlier, on the bank's October 13 earnings call: customers who hand outside agents their credentials take on the risk themselves, described in the coverage as a liability transfer. Read that as an engineer, not a lawyer. The bank is saying: with the evidence a password session produces, we cannot distinguish your instruction from the agent's improvisation, so the loss defaults to whoever created the ambiguity, which is you.

Then the product answer arrived on October 22, and notice where it stops. Brokered login removes the credential from the agent. It does not narrow the session. After the fill, the agent sits inside your account with the same full authority you would have, free to do the asked-for thing and any number of unasked-for things, each one logged as you. The vault solved custody. Nobody has yet solved scope, because scope requires the one artifact neither system produces: a machine-checkable record of the instruction itself.

Treat the Instruction as the Credential

Here is the gap this piece fills. Every explainer of the bank story reaches for detection: better bot signals, better behavior analytics, better session fingerprinting, so the bank can spot the agent. Every explainer of the 1Password launch reaches for custody: keep the secret away from the model. Both leave the session untouched. The fix worth building binds the session to the instruction, so that authority is not "the account, for a while" but "this action, to this payee, up to this amount, until this time," issued against a recorded statement of what the user actually said.

Call that artifact a capability session. It has four parts, none of them exotic:

1. A recorded intent. The user's instruction, captured as data at approval time: action types, named payees, an amount cap, an expiry. Not a prompt the model carries, a record the broker keeps.
2. A brokered start. The user approves that intent on their own device, the way 1Password for Agents approves a login. Approval of a scope, not just of an entry.
3. Enforcement outside the agent. Each action is checked against the intent record by code the agent cannot edit, before it executes. The model proposes; the checker disposes.
4. A receipt per action. Every allowed action writes a receipt naming the capability and the intent it was checked against, into a log the agent cannot rewrite. Denied actions are logged too, with the reason.

Now the bank's impossible question has an answer that fits in one log query: show me the action, show me the intent it cites, show me whether the check passed. Attribution stops being a vibe and becomes a join.

Build the Smallest Version and Watch It Decide

The demo below is standard-library Python, one file, a fixed clock so you get the same output I did. It runs the same six attempted actions twice: once through a legacy session, where the agent logs in as the user, and once through a capability session bound to a single intent.

The intent is deliberately ordinary: "Pay the electric bill to Acme Power, up to $200, today." The capability issued against it allows two action types (read_balance, pay), one payee, a $200 cap, and a 900-second life.

class Capability:
    def __init__(self, cap_id, intent, actions, payees, max_amount, ttl):
        self.id = cap_id
        self.intent = intent
        self.intent_id = intent_hash(intent)
        self.actions = set(actions)
        self.payees = set(payees)
        self.max_amount = max_amount
        self.expires = NOW + ttl
        self.receipts = []

    def act(self, action, payee=None, amount=0, at=NOW):
        if at > self.expires:
            return "DENY expired"
        if action not in self.actions:
            return "DENY action-not-in-intent"
        if action == "pay" and payee not in self.payees:
            return "DENY payee-not-in-intent"
        if amount > self.max_amount:
            return "DENY over-amount-cap"
        receipt = {"cap": self.id, "intent": self.intent_id,
                   "action": action, "payee": payee, "amount": amount}
        self.receipts.append(receipt)
        return "ALLOW receipt=" + json.dumps(receipt)

A few things are worth noting about this example. First, the checks run in a fixed order, expiry before scope before amount, so a denial always names the outermost failure; an expired capability cannot leak whether the payee would have matched. Second, the receipt is written inside the allow path, after every check passes, so there is no route to an allowed action that skips its receipt. Third, the agent holds no secret at all in this half of the demo. The capability is a reference the checker resolves, not a token whose possession is the authority, which is why copying it into a log would be embarrassing rather than catastrophic.

Here is the measured run:

LEGACY borrowed-password session (agent logs in as the user)
  read_balance   payee=None         amount=$0    -> ALLOW
  pay            payee=Acme Power   amount=$142   -> ALLOW
  pay            payee=Acme Power   amount=$260   -> ALLOW
  pay            payee=Stranger LLC  amount=$50    -> ALLOW
  wire_external  payee=Stranger LLC  amount=$100  -> ALLOW
  pay            payee=Acme Power   amount=$40    -> ALLOW
  allowed 6/6; distinct actors in the bank log: {'user'}; intent recorded: none

CAPABILITY session bound to intent 5072656fb84a
  read_balance   -> ALLOW, receipt written
  pay Acme Power $142  -> ALLOW, receipt written
  pay Acme Power $260  -> DENY over-amount-cap
  pay Stranger LLC $50 -> DENY payee-not-in-intent
  wire_external $100   -> DENY action-not-in-intent
  pay Acme Power $40, after expiry -> DENY expired
  allowed 2/6; receipts written: 2, each naming the capability and intent

Read the legacy column the way a bank investigator would. Six actions, one actor, zero intent. The $142 payment the user asked for and the wire they never mentioned are the same row shape. That log is not weak evidence; it is no evidence, and it is the log every password session produces. The capability column answers the post-incident questions in order: what was asked (the intent record), what was allowed (two receipts citing it), and what was refused and why (four named denials, including the quiet one people forget, the late retry against an expired grant).

Run it yourself and change one number at a time:

python3 capability_session.py
python3 capability_session.py | grep -c DENY
# 4
jq -n '{action:"pay", payee:"Acme Power", amount:142}'
# the shape of an action proposal: data for a checker, not a command

Draw the Boundary Where It Actually Sits

  user instruction (recorded as data)
            |
            v
  +------------------+      approve scope       +-----------+
  |  broker / vault  | <----------------------  |   user    |
  |  issues cap-7f3  |    on user's device      |  device   |
  +------------------+                          +-----------+
            | capability: actions, payees, cap, expiry
            v
  +------------------+   proposes action   +------------------+
  |      agent       | ------------------> |     checker      |
  |  (holds no       |                     |  intent record + |
  |   password)      | <------------------ |  receipt log,    |
  +------------------+   ALLOW + receipt   |  outside agent   |
                           or DENY + reason +------------------+
                                                    |
                                                    v
                                              account / bank API

The placement of the checker is the design. Put it inside the agent's process and you have built a suggestion. Put it at the account side, or in a broker the agent must call through, and the agent's opinion about its own authority stops mattering. This is also where the two October 22 stories compose instead of competing: a vault that already verifies the agent and takes approval on the user's device is the natural issuer of scoped capabilities, and a bank that already records every transaction is the natural keeper of the receipt log. Neither needs the other's job. They need the shared artifact between them, the intent record.

Where This Breaks

• Intent capture is the hard part, and it is a user-interface problem. "Pay the electric bill" has to become payees, caps and expiries without turning every delegation into a tax form. Get the confirmation screen wrong and users will approve scopes they did not read, which manufactures the same ambiguity with better typography.
• The checker only governs actions that pass through it. An agent with a general browser session inside the account can route around a capability API entirely. Scoped sessions have to be the only sessions an agent can get, which is a platform decision, not a library decision.
• Payee identity is weaker than it looks. A name string is not a payee. Real systems need account identifiers verified out of band, or the allowlist approves a lookalike name attached to a different account.
• Receipts prove the check ran, not that the intent was wise. A user can be talked into approving a bad scope by the very content the agent was reading. The receipt makes that conversation auditable; it does not make it safe.
• Banks and brokers have to agree on the receipt format before any of this settles a dispute. A beautiful log that the other party does not accept as evidence is an internal metric, not an attribution system.
• Read-only is doing quiet work in the current bank response and it caps the damage, not the confusion. A read-only agent session still exposes balances and history to whatever the agent was reading when it decided to look, and its log still cannot show which reads the user asked for.

Decide Whether Your Agents Need This

Build it if your agents act inside accounts that other parties also have to trust: customer accounts at a bank, a client's cloud tenant, a shared finance tool. The moment a second party will ask "who authorized this action," a password session is a liability you chose. The minimal viable version fits in an afternoon: one intent record per task, one checker function with action, payee and amount tests, one append-only receipt log, and a hard expiry. The demo above is that version, minus persistence.

Skip it if the agent works only inside systems you fully own, with your own logs on both sides and no external party who will ever dispute an action. There, a scoped internal token and a good audit trail get you most of the value without the cross-party receipt format.

One more consideration, because the banks are making it in public: the fallback position, block agents that log in with passwords and allow only approved connections, is coming whether individual teams build this or not. A team whose agents arrive with a recorded intent and receipts can be allowed in. A team whose agents arrive with a borrowed password is a support ticket with a roadmap.

Start With the Log You Wish You Had

Pick your most recent agent incident review, or your most recent near miss, and write down the single question you could not answer. It is almost never "how did it get in." It is "show me where the user asked for that." Then build backwards from that question: the receipt that would answer it, the checker that would have to run to produce it, and the intent record the checker would have to cite. Three artifacts, in that order, and the password can stay in the vault where the October 22 launch correctly put it.

When your agent acts inside someone else's account today, what does the log actually prove: that the account was opened, or that the action was asked for?

Resources

1. Reuters coverage of the Axios bank report, October 22, 2026: the syndicated wire version, including the note that Reuters could not immediately verify the report.
2. What to do now: AI agents in bank accounts: a practitioner walkthrough of the same reporting, including the liability discussion from JPMorgan's October 13 earnings call and the read-only direction banks are moving toward.
3. 1Password Lets AI Agents Log In Without Seeing Your Password: launch coverage of 1Password for Agents, October 22, 2026, describing the agent key, per-login user approval, and direct fill that keeps the credential out of the agent.
4. How to let an AI agent log in without giving it your password: a dev.to walkthrough of the same launch, useful for the supported-agent list and the approval flow as of October 24, 2026.
5. Your Agent Should Not Borrow Your API Key: the earlier piece in this series on scoped, expiring credentials per agent; this piece extends it from API keys to full account sessions.