Enterprise AI demonstrations often end with a successful call to a business system. Delivery raises harder questions: whom does the agent represent, which work order may it change, how much change is permitted, and when does that authority expire? Our analysis is that reusable tool connectivity makes enforceable delegation boundaries more important. The following engineering recommendations draw on public sources; they are not claims about projects delivered or features provided by IDENIFE.
Moving from answers to state changes changes what must be accepted
When an assistant only proposes maintenance advice, an error initially appears as an answer-quality problem. Once it can create work orders, reschedule work or email suppliers, the same misunderstanding can change real business state. The underlying shift is the placement of execution authority in workflows organized by a model. Acceptance based only on answer accuracy and API success misses an important failure: an operation succeeds even though it should never have been permitted.
The Model Context Protocol, or MCP, provides a common interface for connecting tools and resources. It does not define whether a maintenance order may be closed or a purchasing limit exceeded. The authorization specification cited here, version 2025-11-25, primarily addresses authorization for HTTP transports and requires servers to validate that tokens are intended for them.[1] A valid token and a business change that satisfies organizational rules therefore require separate checks. This is an enduring architecture topic, not a presentation of an older specification as breaking news.
Define delegation through four verifiable limits
We propose an authorization budget: a business contract describing the maximum scope of a delegation, rather than a model token budget or an industry standard. It covers four dimensions. Objects specify tenants, projects, equipment and records. Operational limits specify actions, fields, quantities and cumulative allowances. Validity specifies the time window and applicable state versions. Destinations specify the systems and recipients to which data may be sent.
All four must hold together. Permission to help with this week's maintenance orders at Plant A does not imply permission to alter orders at every plant or email equipment information to arbitrary recipients. A responsible business owner sets these limits; the model proposes actions within them. A trusted service must account for cumulative allowances, otherwise splitting a large action into many small calls can exceed the intended boundary.
This changes supplier evaluation. Connector counts indicate integration coverage, but do not establish controllable delegation. Better questions ask whether the server filters object scope, credentials identify the relevant principal, writable fields can be restricted, budgets and validity can be revoked, and every execution entry point passes through the same authorization checks.
Enforce boundaries in both tools and downstream systems
OWASP associates excessive agency with unnecessary functionality, permissions and autonomy, and recommends narrowing tools and enforcing downstream authorization.[2] An enterprise can separate reading work orders, saving proposed responses and submitting state changes before deciding which actions may run automatically. A general tool that executes arbitrary SQL or commands often makes this form of delegation difficult to express.
A tenantId, ownerId or role supplied by the model is not a trusted identity assertion. The service should establish the principal from an authenticated session and recorded delegation, then check the requested object. Where the downstream system accepts only a shared service account, an adapter needs reliable object-level checks and audit attribution to the initiator. Entry points that cannot be covered are rollout limitations, not reasons to treat the shared account's authority as every user's authority.
MCP security guidance rejects token passthrough without proper audience validation.[4] The integration team should explain how credentials intended for the MCP service are separated from, mapped to and revoked alongside credentials used for downstream access. Acceptance needs more than a successful request: demonstrate rejection of an out-of-scope object and establish that rejection caused no business write.
A constructed maintenance scenario separates different kinds of authority
This is a constructed example, not a customer case. Suppose a plant assistant reads equipment alerts, drafts maintenance advice and saves drafts on assigned work orders. Reading and saving advice are preauthorized. Closing an order requires an engineer's approval, while changing equipment control parameters is outside scope. The assistant can organize information autonomously while the business system retains control of actions that change accountability.
Work order T-204 is at revision 17. The proposed closure contains its identifier, target state, inspection evidence and revision 17. The engineer approves that specific proposal. At execution, the server checks the principal's authority, approval expiry and current order revision again. If another person has advanced the order to revision 18, the old approval must not silently govern the new state: the difference needs reassessment. Changing a material approved field triggers the same review.
An alert attachment that asks for all work orders to be exported to an email address is source material, not a new delegation. Even if the model misinterprets it, the tool must reject an unauthorized destination. Similarly, combining ten work orders into a batch requires checking every object and the aggregate allowance. Approval of a batch label alone does not establish that every contained action is authorized.
Place approval where it preserves the value of automation
Requiring a person to confirm every read makes stable workflows hard to operate. A permanent privileged account instead concentrates exposure in every model decision. Our recommendation is to choose controls according to consequences: well-scoped, verifiable reads and draft saves can operate within prior authorization; external commitments, final business states and difficult-to-reverse actions should carry specific approval under organizational policy. This classification is design advice, not a replacement for existing approval rules.
An approval interface should expose the affected objects, material differences, data recipients and validity period. A trusted system issues or stores the approval, and the executor validates its scope. Model-generated text saying 'approved' is not evidence of approval. Repeated submissions should also retain the same business-operation identifier so that one approval cannot produce multiple effects.
Authorization establishes whether execution is permitted; idempotency and recovery establish what happened after execution. They must work together without collapsing into a single success flag. See idempotency and recovery in multi-agent execution for why a network interruption requires querying the actual outcome before continuing.
Containment limits reach but does not establish business correctness
Anthropic's public engineering account distinguishes environment constraints from model behavior defenses. It describes sandboxes, filesystem boundaries and egress controls, and notes that a reviewed connector can still retrieve untrusted content.[3] The enterprise implication is practical: choosing a stronger model does not remove the need to accept runtime boundaries and tool permissions as separate deliverables.
A work-order system reachable from a sandbox can still contain orders the agent should not close. An allowed network domain alone cannot distinguish a legitimate maintenance report from an export of every equipment record to that same domain. Containment limits reach; business authorization limits actions within that reach. If either is missing, reduce the scope of automatic execution.
The costs belong in the design too. Fine-grained tools increase adapter maintenance, authorization checks add latency, approvals introduce waiting, and temporary delegations require expiry and renewal management. For infrequent, irreversible workflows with unsettled rules, advice and reviewable drafts may be more economical. For frequent workflows with clear boundaries, encoding policy in trusted services can reduce repeated human judgment.
Accept delegation through negative tests and revocation exercises
An acceptance suite should include permitted operations, cross-tenant objects, revoked permissions, expired approvals, post-approval parameter changes, exceeded cumulative allowances and extra instructions embedded in source material. Define the expected outcome for every case in advance. For a rejection case, verify the absence of unauthorized side effects; an assistant merely stating that it lacks permission is insufficient.
Three useful observations are legitimate-task completion rate, with only tasks meeting all prerequisites in its denominator; authorization escapes, counting actual actions outside delegation; and revocation propagation delay, from authoritative revocation to consistent rejection at execution entry points. We do not propose universal passing thresholds. Organizations should set targets according to business consequences and recovery capacity, and retain the scope of test coverage.
Audit evidence should connect the principal, delegation, approval, tool request and downstream business receipt without retaining raw credentials or unnecessary sensitive content. After rollout, exercise revocation across queued tasks, long sessions and cached approvals. These records establish which parts of a workflow an enterprise can delegate and under what conditions it can withdraw execution authority.