This is the second post in our AI Agent Signing Infrastructure series, which covers what needs to exist - technically and legally - before AI agents can sign contracts in a way that is sound and auditable. Subnoto builds confidential e-signatures today; this series covers where we think the space is going. It is not legal advice; application varies by jurisdiction.
This post is most relevant for engineering teams designing agent signing systems, legal and compliance teams defining governance policy for autonomous agents, and CTOs evaluating the infrastructure required before deploying agents with contractual authority.
A delegation scope is a formal, tamper-evident record that defines the exact limits of an AI agent’s signing authority. It is the AI-native equivalent of a limited power of attorney. Before an agent can sign any contractual document, a human principal must define and approve a delegation scope. Every signature the agent produces is only legally valid within those limits - and an immutable audit trail proves it.
The problem delegation scopes solve
AI agents are now capable of creating, negotiating, and executing contracts autonomously. An agent managing vendor relationships can renew a SaaS agreement the moment it detects an upcoming expiry. An agent handling M&A due diligence can generate and co-sign an NDA before a data room is accessed. An agent managing energy assets can commit to a supply contract in real time based on grid conditions.
This is operationally powerful. It is also legally dangerous without a clear framework - because an agent that can sign anything is a principal that has surrendered all control.
The gap is that nobody has built proper governance infrastructure for this yet. Organizations deploying signing agents today are largely improvising - informal approval processes, generic API keys, signing platforms not designed for autonomous actors. The delegation scope is the core concept that changes that. Here is how we think it should work.
For a full breakdown of who bears legal responsibility when an agent signs, see Who Is Legally Responsible When an AI Agent Signs a Contract?.
What a delegation scope contains
A well-formed delegation scope needs six components. This is our proposed architecture - not a published standard, but grounded in existing mandate doctrine and the direction of DORA and eIDAS 2. All six are required for the delegation to be legally defensible.
1. Authorized document types
Specifies exactly which categories of contractual documents the agent is permitted to sign.
Examples:
- Non-disclosure agreements (mutual and unilateral)
- Purchase orders below a defined value
- SaaS subscription renewal agreements
- Data processing agreements (DPAs)
- API access and data room access agreements
An agent authorized to sign NDAs has no authority to sign a service agreement - even if the service agreement is lower in value. Document type authorization is categorical, not just financial.
2. Financial ceiling
The maximum total contractual value the agent can commit to in a single act.
Example: an agent may sign purchase orders up to €50,000. An attempt to sign a €51,000 purchase order is automatically rejected and flagged to the principal, regardless of the document type.
The financial ceiling should reflect your organization’s internal approval matrix. An agent should never be authorized at a level that would otherwise require human board or executive sign-off.
3. Counterparty whitelist
The specific organizations or categories of organizations the agent is permitted to contract with. This is typically defined using:
- Legal Entity Identifiers (LEIs): the ISO 17442 standard identifier for legal entities, increasingly mandatory in financial and institutional transactions. An LEI-based whitelist ensures the agent can only contract with verified, registered legal entities.
- Domain-based allowlists: e.g., the agent may sign with any entity whose email domain is on an approved list.
- Explicit named counterparties: the agent may only contract with a specific list of vendors.
A counterparty whitelist prevents agents from being manipulated into signing with malicious or unintended parties - whether through prompt injection, supply chain compromise, or simple misconfiguration.
4. Validity period
The delegation scope has a defined start date and expiry date. After expiry, the agent’s signing authority lapses automatically. A new scope must be reviewed and approved by the principal to restore it.
Recommended practice: validity periods of 30 to 90 days, with renewal requiring an active human approval step. This ensures the principal reviews the agent’s authorization regularly rather than granting indefinite authority. Short validity periods also limit the blast radius of a compromised agent: even if an agent’s credentials are stolen, the attacker’s window to abuse signing authority is bounded.
5. Revocation conditions
The conditions under which the delegation scope is immediately suspended, without waiting for expiry. These should include:
- Anomaly detection triggers (e.g., more than N signatures in a 24-hour period)
- Security alerts from the infrastructure layer
- Explicit revocation by the principal at any time
- Automatic suspension if the agent’s machine identity certificate is revoked
Revocation should be instantaneous and should produce an audit event.
6. Signature evidence requirements
Defines what proof the agent must produce with each signature - specifically, what must be included in the Signature Evidence Package. This typically includes:
- SHA-256 hash of the document at the moment of signing
- The agent’s verified machine identity (certificate fingerprint)
- The active delegation scope identifier and hash
- A certified RFC 3161 timestamp
- Hardware attestation (TEE attestation) if required by compliance framework
For DORA-regulated organizations and M&A workflows, TEE attestation should be mandatory - it is the component that makes the audit trail independently verifiable by a regulator or court.
How delegation scopes work technically
Token-based enforcement
When a principal creates and approves a delegation scope, the signing platform generates a signed scope token - typically a JWT (JSON Web Token) or PASETO - that cryptographically encodes the scope parameters. The agent presents this token with every signature request.
The signing backend validates three things before issuing a signature:
- The scope token is valid and has not been tampered with
- The requested signature act falls within all scope parameters (document type, value, counterparty)
- The scope has not expired or been revoked
If any check fails, the signature is rejected, an alert is generated, and the attempt is logged.
What a delegation scope looks like in practice
{ "scope_id": "scope_procurement_q2_2025", "principal": { "entity": "Acme Corp", "lei": "ABCD1234567890EFGH56", "approval_timestamp": "2025-04-01T09:00:00Z" }, "agent": { "identity_type": "spiffe", "identity": "spiffe://acmecorp.com/agents/procurement-bot-v2", "certificate_fingerprint": "sha256:abc123..." }, "authorized_document_types": ["purchase_order", "vendor_nda"], "financial_ceiling_eur": 50000, "counterparty_whitelist": { "type": "lei_list", "values": ["LEI001...", "LEI002...", "LEI003..."] }, "valid_from": "2025-04-01T00:00:00Z", "valid_until": "2025-07-01T00:00:00Z", "revocation_conditions": { "max_signatures_per_day": 200, "auto_revoke_on_anomaly": true }, "evidence_requirements": { "document_hash": true, "tee_attestation": true, "rfc3161_timestamp": true }}This scope token is signed by the platform and presented by the agent with each API call. The backend verifies the token before processing any signature request.
Enforcement inside a TEE
The most legally robust implementation runs scope enforcement inside a hardware-level Trusted Execution Environment (TEE) - such as Intel SGX or AMD SEV-SNP. This means the check “is this act within the scope?” happens in an encrypted enclave that neither the platform operator, the cloud provider, nor any attacker can observe or tamper with.
The TEE produces a remote attestation - a cryptographic proof signed by the chip manufacturer - that certifies the exact code that ran in the enclave, that it ran in a non-tampered environment, and that the private key used to sign never existed outside the enclave.
This attestation is included in the Signature Evidence Package. It means the audit trail is not just a log - it is a log whose integrity is guaranteed by hardware, and which any third party (including a court or regulator) can verify independently.
Why the delegation scope is the product, not the signature
Most e-signature vendors treat the signature as the product. The workflow is: prepare document, send to signer, signer clicks, signature recorded.
For AI agent signing, this model inverts. The signature itself is the easy part - a private key operation that takes milliseconds. The hard part is the governance: who authorized what, within what limits, and can you prove it?
The delegation scope governance console is where most of the value lives. It is the interface where legal teams define what agents are permitted to sign, finance teams set financial ceilings by agent and document category, security teams configure revocation triggers and anomaly alerts, and compliance teams export audit packages for regulators.
When a principal configures delegation scopes over months, they are not just using a software product - they are encoding their organization’s legal and commercial policies into a machine-readable, auditable record. This accumulated configuration is the organizational legal memory.
Delegation scopes and legal validity
The mandate doctrine
Under civil law systems (France, Germany, most of the EU), a mandatary who acts within the limits of their mandate binds the principal. The mandate must be sufficiently defined to identify what acts are authorized.
A delegation scope is a machine-readable mandate. For it to be legally sound, the scope must be:
- Approved by an authorized principal - the person or body within the organization who has actual authority to grant signing power at the defined level
- Specific enough to be interpreted - “sign any document” is not a valid mandate; “sign NDAs with no financial commitment to LEI-verified counterparties” is
- Stored in a tamper-evident record - to prove in a dispute that the scope existed and was in force at the time of signing
eIDAS 2
The EU’s eIDAS 2 regulation, currently being implemented, extends electronic signature frameworks to include qualified electronic attestations of attributes. This creates a pathway for delegation authority itself to be cryptographically certified - not just the signature, but the authorization to sign. Delegation scope architecture designed to align with this direction will increasingly satisfy qualified mandate requirements in regulated workflows as eIDAS 2 implementation matures.
Common mistakes when configuring delegation scopes
Too broad a financial ceiling. Setting the ceiling at “the maximum that doesn’t require board approval” rather than “the minimum sufficient for the agent’s actual workflow.” If a procurement agent only ever processes orders under €10,000, its ceiling should be €10,000 - not €250,000.
No counterparty whitelist. Allowing an agent to sign with “any” counterparty exposes the organization to social engineering and prompt injection attacks. An attacker who gains influence over an agent’s inputs can direct it to sign with a fraudulent entity.
Long validity periods without review checkpoints. A scope valid for 12 months means 12 months of potential exposure if the agent is compromised or if the organization’s policies change. Thirty to ninety day validity periods with active renewal force periodic human review.
No anomaly-based revocation. If an agent signs 20 contracts per week normally and suddenly signs 200 in a day, that is a signal something is wrong. Automatic revocation triggers on statistical anomalies are a basic safety layer that most organizations deploying signing agents have not yet configured.
Storing scopes in a mutable database without audit. A delegation scope stored in a database that can be modified without logging is not a legally sound mandate record. Any change to a scope - including deletion - must produce an immutable audit event, timestamped and signed.
Delegation scopes across use cases
M&A due diligence
An onboarding agent that manages counterparty introduction and NDA workflow would operate under a scope covering mutual NDAs only, with no financial ceiling (NDAs carry no financial commitment), counterparties limited to LEI-verified entities in a pre-approved industry sector, a 90-day validity period renewable per transaction mandate, and TEE attestation as a mandatory evidence requirement.
SaaS contract renewal
A procurement agent that monitors contract expiry and executes renewals would operate under a scope covering SaaS subscription renewals only, a financial ceiling of €25,000 per renewal, counterparties limited to an existing approved vendor LEI list, 30-day validity with auto-renewal if no changes in vendor status, and document hash plus timestamp as sufficient evidence.
DORA data access agreements
An API integration agent requesting access to partner data systems would operate under a scope covering data access agreements and DPAs, no financial ceiling, counterparties limited to regulated EU financial sector entities filtered by LEI and regulatory registration status, 30-day maximum validity (DORA requires periodic review of third-party access), and mandatory TEE attestation to satisfy regulatory audit requirements.
Frequently asked questions
Q: What is a delegation scope in AI agent signing?
A delegation scope is a formal, machine-readable record that defines the exact limits of an AI agent’s contractual signing authority. It specifies which document types the agent can sign, up to what financial value, with which counterparties, and for how long. It is the AI-native equivalent of a limited power of attorney, and it is the mechanism that makes agent signing legally defensible.
Q: Who creates a delegation scope?
A delegation scope must be created and approved by a human principal - the individual or body within an organization who has the actual legal authority to grant signing power at the defined level. For example, a CFO might approve a delegation scope for a procurement agent up to €50,000, matching their own delegated financial authority.
Q: What happens if an agent tries to sign outside its delegation scope?
The signature request is rejected automatically. An alert is generated and logged. The rejection event - including what was attempted and by which agent - is included in the audit trail. The agent does not receive an error that reveals the scope limits, to prevent scope-probing attacks.
Q: Is a delegation scope the same as an API key?
No. An API key authenticates the caller - it proves that the request comes from someone with access to the key. A delegation scope authorizes the action - it defines what that caller is permitted to do. Both are necessary. An API key without a delegation scope is authentication without authorization. A well-formed agent signing system requires a verified machine identity plus a registered delegation scope.
Q: How does a delegation scope relate to a power of attorney?
A delegation scope is the machine-native equivalent of a limited power of attorney. A power of attorney grants a person authority to act on behalf of another within defined limits. A delegation scope grants an AI agent authority to sign on behalf of a principal within defined limits. The legal theory is identical; the implementation is adapted for machine identity and automated enforcement.
Q: Can a delegation scope be revoked?
Yes, immediately and at any time. Revocation takes effect instantly - the agent’s signing authority lapses from the moment the scope is revoked. All revocation events are logged with a timestamp and the identity of the revoking principal.
Q: What is the difference between a delegation scope and a signing policy?
A signing policy is an internal governance document - it describes what is allowed. A delegation scope is a technical and legal enforcement record - it defines and enforces what is allowed at the moment of signing. A policy can be violated. A delegation scope, properly implemented, cannot be exceeded without producing a documented rejection event.
Summary
A delegation scope is the governance layer that makes AI agent signing legally sound. It defines what an agent can sign, up to what value, with which counterparties, and for how long - and enforces those limits at the moment of every signature request. Combined with verified machine identity and hardware-attested audit trails, delegation scopes transform agent signing from a legal liability into a compliant, auditable, and organizationally controlled process.
The organizations deploying agent signing without delegation scopes are not moving faster - they are accumulating silent legal risk. The organizations that invest in delegation governance now are building the infrastructure on which their entire automated contracting operation will safely run.
About Subnoto
Subnoto is a French e-signature company built on confidential computing - documents and signing sessions stay encrypted throughout server-side processing, using hardware-level isolation (Intel SGX / AMD SEV). We currently provide confidential e-signatures for teams and developers who handle sensitive contracts and can’t afford to expose document contents to a third-party platform.
The delegation scope architecture described in this post is how we think agent signing governance should work. We are building toward it. We don’t have it fully built yet - and we are talking to the organizations that will need it first to make sure we get the design right.
We’re particularly interested in hearing from engineering teams designing agent signing systems from scratch, legal or compliance teams defining what governance over autonomous agents should look like, and organizations in regulated sectors - financial services, legal tech, healthcare - where the audit requirements make the stakes concrete. If that’s you, we’d like to understand your constraints before we finalize ours.