Agent profiles can separate identities and make activity easier to track. They do not create accountability for an AI agent’s purchases, trades, or spend—because accountability is about who owns scope, approvals, escalation, and revocation with logs that hold up under scrutiny.

If an agent can commit spend or move money, you need a named human who can say: this is what the agent is allowed to do, this is what it must never do, here is the approval gate, here is how we stop it at 2am, and here is the audit trail that proves what happened.

Do “agent profiles” make an AI agent accountable?

No: an agent profile is an identity wrapper, not a governance system. It can tell you which agent credential was used, but it can’t tell you why an action was permitted, who approved it, or who was accountable to stop it when it went wrong.

This matters because the market conversation is drifting toward “identity as control plane.” TechCrunch reported that Walmart introduced an “Agent Gateway” and “Agent Profiles” intended to authorize agents and track purchases separately, bringing agent commerce closer to production workflows (TechCrunch). The Wall Street Journal likewise reported that 1Password is positioning around “growing challenges around security, access and trust” as agents proliferate (WSJ).

Those are necessary moves. If an agent is going to touch purchasing, billing, or treasury-like workflows, it should have a distinct identity and constrained credentials. But the opposing view—“give the agent its own profile and you’ve solved responsibility”—fails in three predictable ways.

• Profiles solve attribution, not authority. They help you answer “which credential did this,” not “who authorized this class of action and under what conditions.”
• Profiles don’t resolve ambiguity. When an agent turns a vague instruction (“restock,” “renew,” “roll over”) into a concrete commitment, the risk is in the interpretation, not the identity.
• Profiles don’t create a stopping function. You still need an on-call human, a kill switch, and a rollback plan that’s been exercised.

The governance unit is not a profile. It’s a delegation: a written scope; explicit non-responsibilities; an approval gate; an escalation path; and a revocation plan, owned by a specific human. That’s what turns “agent activity” into something an organization can defend.

Who signs when an AI agent can purchase, trade, or commit spend?

A human signs, even when the agent executes. If money moves, the organization still needs a named person who is accountable for the delegation: what the agent is allowed to do, what it cannot do, and what approvals are required.

One reason this question is getting sharper is that mainstream coverage is normalizing agent execution in sensitive domains. The Wall Street Journal reported skepticism from Charles Schwab’s CEO about agents trading “while you sleep,” emphasizing that some decisions “require a human touch” (WSJ). Separately, the Journal also reported that AI agents create “new headaches” for online sellers as agents insert themselves between buyer and merchant (WSJ).

The wrong way to respond is to look for a single “responsible entity” inside the software—an agent profile, a credential manager, a policy engine—and call it done. The right way is to treat agent execution like any other delegated operational capability: the approver must be explicit and the boundaries must be legible.

Practically, “who signs” becomes a set of design decisions you can write down:

• Scope owner (accountable human): owns the delegation document and accepts that the agent’s allowed actions are an extension of their authority.
• Approver (can be the same person, but doesn’t have to be): explicitly approves high-risk actions (new vendor, new bank destination, new spend category, threshold crossings).
• Operator (on-call): has the authority to pause execution and revoke access, without negotiating with the tool during an incident.

Identity systems can name the agent. They don’t tell you who had the organizational authority to grant that agent permission in the first place, or who was on the hook to intervene when approvals were ambiguous.

If you want a simple test: ask whether your current setup can answer this in one sentence, with links to evidence: “This person approved this action at this time, using this process.” If the answer is “the agent decided,” you don’t have ai agent accountability—you have unowned approvals.

What does “revocation” mean in agent commerce (not in theory)?

Revocation means you can stop the agent now, and you can prove you stopped it: disabling credentials, terminating sessions, blocking connectors, and preventing re-authorization through cached tokens or over-permissioned pathways.

The operational reality is that agent commerce tends to be a chain: model → tool/router → connector → third party. Revocation has to work across the chain, not just at one layer. If you only revoke at the identity layer but the connector still has a long-lived token, your “kill switch” is theater. If you only revoke at the connector but the agent can re-auth via an unattended flow, you haven’t really revoked.

CSO Online framed a related security argument as “containment and monitoring failures” being behind many AI hacking reports (CSO Online). You don’t need to assume malice to learn the lesson: the most common failure mode is that teams build the exciting part (execution) and postpone the boring part (containment, monitoring, and stopping).

So define revocation in concrete terms, before the agent gets permission to spend:

• Credential revocation: rotate keys, invalidate tokens, disable the agent identity, and ensure there is no fallback secret stored elsewhere.
• Connector revocation: remove app authorizations at the third-party side (merchant account, payments provider, banking integration) and confirm token invalidation semantics.
• Policy revocation: update the allowlist/denylist so the agent can’t immediately regain equivalent power under a new identity.
• Execution revocation: stop queued jobs, cancel in-flight transactions when possible, and prevent retries from background workers.

Most importantly: revocation needs an owner. If you can’t point to the person who is authorized to hit the stop button and the person who must be paged when the stop button is hit, you don’t have revocation—you have hope.

If you want a deeper version of the revocation problem statement, this pairs with How do you revoke an AI agent’s access (for real)?.

What logs do you need to prove who approved what an agent did?

You need logs that connect four things in one trace: the human instruction, the agent plan, the approval event, and the executed action—plus the credential used and the policy that allowed it.

In practice, teams often have plenty of raw events but not a defensible story. An audit log that says “agent_profile=PurchasingBot created order #1234” is not enough if the real question becomes: who authorized the bot to place that order, why that vendor, and why that amount. When money moves, “we can reconstruct it” is not a plan; auditors and incident responders need the system to already have the joins.

Design your logging around accountability questions, not developer convenience:

• Delegation record: the written scope and explicit non-responsibilities, versioned, with a named owner and effective dates.
• Approval record: who approved (human identity), what they approved (structured fields, not just chat text), and what policy/threshold triggered approval.
• Execution record: tool call, parameters, target system, and result (success/failure), tied to a stable run id.
• Permission record: what credential was used, what permissions it had at the time, and what policy decision allowed it.
• Intervention record: pauses, revocations, overrides, and rollbacks, with the human who performed them.

This is also where “agent profiles” fit well: they provide a stable identity to anchor the execution and permission records. But they don’t generate the delegation record, they don’t decide when approval is required, and they don’t guarantee intervention authority.

If your team is still debating “who signs,” see Who signs for an AI agent’s actions? for a tighter framing: accountability can’t be delegated, only work can.

Operational checklist: ship an agent execution boundary this week

You can improve ai agent accountability without waiting for a new platform feature. Ship a boundary that makes scope, approval, and revocation real.

• Write one delegation page. One owner, one purpose, explicit non-responsibilities, and a spend/commitment ceiling. If you can’t write the non-responsibilities, the scope isn’t ready.
• Add a single hard approval gate. Pick one trigger you will never allow the agent to cross without a human approval (new payee, new vendor, destination account change, or threshold crossing). Make it block by default.
• Implement a 2am kill switch. Document exactly how to revoke: where to disable the agent identity, where to revoke third-party authorizations, and how to stop queued execution. Assign an on-call human.
• Log the “approval join.” Ensure every executed action can be joined to an approval event or an explicit “no approval required” policy decision, with a run id.
• Run one failure drill. Simulate an over-permissioned connector or a mistaken approval, then practice revocation and evidence capture. Time how long it takes to stop and explain.

Notice what isn’t on the list: “pick the right agent profile product.” Identity wrappers, gateways, and credential managers are useful building blocks, and the Wall Street Journal reported vendors positioning to meet that need (WSJ). But they are not governance by themselves. Governance is a delegation with an accountable human and evidence-producing controls.

If you’re trying to formalize this without turning it into a bureaucracy project, Almma publishes a plain approach to governance and safety built around scoped tasks, written non-responsibilities, escalation paths, a named accountable human, human override, and a full audit trail. We won’t pretend a tool can “own” responsibility, but we can help you design the delegation so approvals, revocation, and logs are real: https://almma.ai/safety-governance/.

Frequently asked questions

Who is accountable when an AI agent makes a purchase or moves money?

A named human is accountable, because accountability can’t be delegated to software. The agent can execute, but a person must own the delegation: scope, approval rules, escalation, and revocation.

Are agent profiles still worth using?

Yes—profiles are useful for separating identities and improving attribution. Just don’t confuse attribution (“which agent did this”) with governance (“who approved this and who could stop it”).

What’s the minimum evidence I should be able to produce after an incident?

You should be able to show the delegation scope, the approval (or policy decision) that allowed the action, the exact tool call and credential used, and the revocation/intervention steps taken. If any of those are missing, you’ll end up arguing from memory.

Sources

• CSO Online: “Containment and monitoring failures are to blame for AI hacking reports: experts”
• TechCrunch: “Walmart unveils Agent Gateway… and Agent Profiles…”
• Wall Street Journal: “1Password Surpasses $500 Million in Revenue as AI Agents Drive Growth”
• Wall Street Journal: “AI Agents Trading Stocks While You Sleep? Charles Schwab’s CEO Is Skeptical”
• Wall Street Journal: “AI Agents Bring New Headaches to Online Sellers”