Agentic AI Wiki
AI Blog / An account toggle is not a power of attorney
AI Blog

An account toggle is not a power of attorney

On 4 September Docusign said its MCP server opens to every agent on 30 September — Claude, ChatGPT, Gemini, Copilot, Slack, any MCP client — governed by account-level admin controls. The law has allowed an automated agent to bind its principal since 1999, on one condition: the act must be attributable to that person. A per-account toggle attributes a class of acts, which is what carried deterministic scripts and is exactly what a model that negotiates strains. Closing that gap is the deployer’s job, and nothing in MCP does it for you.

By Agentic AI Wiki 14 min read

The interesting thing about Docusign opening its MCP server to every agent on 30 September is not that agents can now reach your agreements — it is that the law has permitted an automated program to bind its principal since 1999, and asks for exactly one thing in return: that the act be attributable to the person to be bound. The announcement names account-level admin controls. An account-level control attributes a whole class of future acts in advance, which is what made a deterministic script attributable and is precisely the weight a model that reads clauses and negotiates terms cannot carry. That gap is not Docusign's to close. It is yours.

What was announced

On 4 September 2026 Docusign said it will open its Model Context Protocol server to every AI agent on 30 September. The pitch is that agreement intelligence and what the company calls "governed action" become callable natively from Claude, ChatGPT, Gemini, Copilot, Slack and any other MCP client, drawing on the full context of past negotiations, accepted terms, clauses and company policy through Iris, Docusign's AI engine, across Intelligent Agreement Management and CLM workflows. The enterprise framing is three items: account-level admin controls, global multi-region infrastructure, multilingual support. CEO Allan Thygesen's line is that agents "require a robust framework to analyze terms and execute end-to-end agreement workflows."

ElementWhat it isWhat it changes
MCP server, open to all clients Any MCP-speaking agent, not a named partner list The client is chosen by the user, not vetted by the vendor
Iris context Past negotiations, accepted terms, clause library, policy The agent argues from your own precedent, not generic drafting
"Governed action" Executing agreement workflows, not just reading them The tool call has legal consequence, not just informational value
Account-level admin controls Per-tenant configuration of what agents may do The unit of authorisation is the account, not the agreement

Every row above is ordinary enterprise-software news except the last two read together. A system of record whose whole product is the evidentiary weight of a record has just made that record producible by a process, and the dial that decides whether it may is set once, per tenant, by an administrator who will not be in the room when it fires.

The law solved this in 1999, and the answer was attribution

Two paths to the same signed agreement The upper path is the classic signing ceremony: a named person authenticates, is shown the document, performs a deliberate act, and the certificate of completion binds identity, authentication method, timestamp and document hash to that person. The lower path is the agent path: a prompt, a model decision, an MCP tool call carrying an OAuth client credential, and the same envelope produced — but the record names an integration, and the human intent that permitted it sits far upstream in an account setting an administrator made months earlier. Where the act of intent sits Signing ceremony Named signer Authenticates as herself, is shown the document. Deliberate act A click that means “I intend to sign this.” Certificate of completion Identity, auth method, timestamp, document hash. Attributable The record names the person to be bound. The pre-authorisation and the act are the same event, seconds apart, on one record. Agent path via the open MCP server Prompt in a client Slack, ChatGPT, Claude — whichever the user installed. Model decides Reads clauses and policy, picks terms and a recipient. MCP tool call Carries an OAuth client id and a scope. Nothing more. Same envelope The record names an integration, not an intent. Account-level admin control Set once, months earlier, by someone not in the room. The only human decision in the lower lane is up here — a class permission, standing in for a per-act intent.
Both paths produce the same artefact. Only one of them records who meant it.

A recurring reflex in agent commentary is that agents cannot sign things because signing requires a human. That has never been the law. ESIGN and UETA both define an electronic agent — a program or automated means that initiates an action or responds to records without human review of each individual action — and UETA § 14 says a contract may be formed by the interaction of electronic agents, or of an agent and a person, and is not invalid merely because no individual reviewed it. eIDAS and the UK Electronic Communications Act reach a similar place by a different route. Automated contracting has been statutorily fine for a quarter of a century; it is how EDI, procurement portals and every click-through in your life already work.

What the statutes ask for instead is attribution: the act must be legally attributable to the person or entity to be bound, and there must be a record capable of showing it. This is where the e-signature industry earned its money. The certificate of completion is not decoration — it is the thing that survives a challenge, binding an authentication event, a timestamp, an IP address and a document hash to a named signer who was shown the document and did something deliberate. Docusign's franchise is that record.

So the question raised by an open MCP server is not whether an agent may act. It is what the record says when it does, and whether that record answers the only question a dispute ever asks.

Why a per-account toggle used to be enough, and why it stops being

Attribution for a deterministic electronic agent works by an argument about specification. The principal configured the program; the program's behaviour is a function of that configuration; therefore its output is the principal's act. A purchase-order system that fires a reorder at a stock threshold is attributable because the threshold was chosen by someone with authority, and anyone can inspect the rule and confirm what it would do. The pre-authorisation covers the class of acts because the class is closed and enumerable.

An account-level admin control is an attempt to run the same argument. "Agents may execute agreement workflows in this tenant" is a class pre-authorisation, made once, by an administrator, over a class whose members nobody has enumerated — because the member set is whatever a language model decides to do next given a clause library, a counterparty's email and a prompt from a salesperson under quota. The configuration no longer determines behaviour; it merely permits it. That is a different logical relationship, and it is the one the attribution argument was resting on.

Three units of authority Three columns comparing units of authority for an agent-initiated agreement. The account toggle is granted once by an administrator, scopes every agreement in the tenant, is bounded by nothing the record captures, and answers only whether agents may act here. The OAuth scope is granted by a user at connect time, scopes an API surface, is bounded by token lifetime, and answers what a client may call. The per-act delegation record is granted by the principal for a named matter, scopes a counterparty and a value ceiling with an expiry, is bounded to the artefact, and answers whether this person authorised this agreement. What each unit of authority actually says Account toggle Granted by: an administrator, once, in advance. Scope: every agreement in the tenant. Answers: may agents act here? A class permission over a class nobody has enumerated. OAuth scope Granted by: a user, at connect time. Scope: an API surface, bounded by token lifetime. Answers: what may this client call? Overwritten on every refresh, so it keeps no history. Per-act delegation record Granted by: the principal, for a named matter. Scope: counterparty, ceiling, expiry, artefact hash. Answers: did she authorise this one? The row no vendor issues and every dispute asks for.
Only the right-hand column answers the question a dispute asks.

Notice that the middle column does not rescue you either. MCP's authorisation story is OAuth 2.1, and an OAuth access token identifies a client and a scope. It has no standard way to say this action is taken on behalf of Dana Okafor, for the Northwind renewal, up to £250,000, until Friday. The identity working groups know this; the practical position today is that the protocol carries a credential and the on-behalf-of semantics live in whatever your application invents. We wrote about the same hole from the protocol-governance side when A2A moved in with MCP and the identity layer stayed outside. Docusign opening its server does not create that hole. It routes a legally consequential act straight through it.

What actually travels with the tool call

Which artefact answers which attribution question A four-by-four matrix. Rows are the OAuth access token, the MCP tool call, the e-signature certificate of completion, and a per-act delegation record. Columns ask whether each names the human principal, names the acting agent, bounds this specific act, and survives as history after revocation. The token and the tool call name only a client id and keep no durable history. The certificate names the signer and the document strongly but says nothing about an agent or a delegation. Only the delegation record answers all four, and it is the row nobody currently issues. Attribution coverage by artefact Names the human principal Names the acting agent Bounds this specific act Survives as history OAuth access token No Client id only No Overwritten MCP tool call No Client id only No If you trace it Certificate of completion Strong Silent Document hash Retained Per-act delegation record Strong Strong Scope + expiry Append-only Absent Partial Answers the question The bottom row is the one no vendor issues for you.
Four artefacts, four questions, and the one row nobody is issuing.

Read across the rows and the shape of the problem is plain. Each artefact is excellent at the job it was designed for, and no combination of them reconstructs the sentence a court, a counterparty or your own auditor will ask you to produce. The certificate of completion is strong precisely where the agent path is weak: it names a person and an act. The tool call is strong precisely where the certificate is silent: it names the machine and the moment. Nobody joins them, because no field exists to join them on.

The practical failure is not dramatic. It looks like this: eight months from now a counterparty disputes a renewal term. You pull the certificate of completion; it names your VP of Sales, because the envelope was sent under her account. She has no memory of the agreement, because an agent drafted and dispatched it from a clause library while she was on a plane, under an admin setting made by IT in September. Your logs show an MCP call from a client id. Somewhere there is a Slack message that started it. Reconstructing intent is now an archaeology project across three systems with different retention policies — which is the specific failure delegated access and consent records exists to prevent, and it lands hardest on exactly the organisations that adopted fastest.

It is worth being precise about what is and is not being claimed here. Docusign's announcement describes account-level administrative controls; it does not describe a per-agreement delegation record, and I have not seen the API surface that ships on 30 September. It is entirely possible the product carries more than the press release says. What is certain is that MCP itself carries none of it, that the client is now whatever the user installed, and that the obligation to produce an attributable record falls on the deployer regardless of which vendor's server is in the path.

What to build before 30 September

None of this argues for staying off the MCP server. The agreement layer is genuinely one of the highest-value places to put an agent — the context is proprietary, the drafting is repetitive, and the cycle-time win is real. It argues for issuing the record the statutes assume exists.

  • Emit a delegation record at grant time, not at act time. Five fields: the principal, the agent identity, the scope in business terms (counterparty, matter, value ceiling), the expiry, and the human-readable purpose text the principal was actually shown. Append-only. An ID, not a boolean.
  • Stamp that ID on every envelope the agent creates, in a custom field that lands in the audit record. This is the join key that does not exist today, and it costs an afternoon. Everything downstream — dispute, audit, revocation, erasure — becomes a query instead of an archaeology project.
  • Split reading from executing, and gate on irreversibility rather than on value. Iris context retrieval and clause analysis are read paths; nobody needs a delegation record to summarise a negotiation history. Send, countersign and amend are the acts that produce evidence, and they are a much smaller surface than the announcement's framing suggests.
  • Keep the ceremony where the intent is. An agent that assembles a perfect envelope and routes it to a named human for the signing act loses almost none of the cycle-time benefit and keeps the attribution argument intact. The expensive part was the drafting, not the click.
  • Decide now which client ids you accept. "Any MCP client" means a user with a personal ChatGPT connector can reach your tenant's agreement layer through a path your security review never saw. The account-level control is blunt, but it is the control you have — set it before the 30th rather than after the first surprise.

The one-line version: the toggle answers may agents act here, and the question you will be asked is did this person authorise this agreement. Those are different sentences, and only one of them is worth anything eight months later.

FAQ

Can an AI agent legally sign a contract?

Yes, with a caveat that carries all the weight. ESIGN and UETA both recognise electronic agents, and UETA § 14 provides that a contract may be formed by their interaction without any individual reviewing it. The requirement is attribution — the act must be legally attributable to the person or entity to be bound, supported by a record capable of showing it. The legal question is not permission; it is evidence.

What exactly is Docusign opening on 30 September?

Its MCP server, to every MCP client rather than a named partner list, exposing agreement intelligence and agreement-workflow execution powered by its Iris engine across Intelligent Agreement Management and CLM. The announcement of 4 September names account-level admin controls, multi-region infrastructure and multilingual support as the enterprise guarantees.

Does MCP have a way to express "acting on behalf of" a person?

Not as a standard primitive. MCP authorisation builds on OAuth 2.1, which identifies a client and a set of scopes. There is no normative field carrying principal, delegated scope in business terms, or expiry for a specific act, so any on-behalf-of semantics live in application-level convention today.

Is an account-level admin control sufficient governance?

It is necessary and it is the wrong grain. It answers whether agents may act in a tenant, once, in advance. It cannot answer whether a particular person authorised a particular agreement, which is the question a dispute, an auditor or a revocation request actually asks.

What is the smallest useful thing to build first?

A delegation record with an ID, stamped onto every agent-created envelope in a custom field that lands in the audit record. That single join key converts every later question from a reconstruction across three systems into a lookup.

Further reading

On this wiki:

Sources: