MCP Connects Tools. It Does Not Govern the Work.

Consider an illustrative employee offboarding scheduled for 17:00. The workflow reads the worker's status from the HR system, finds active accounts, disables sign-in, revokes sessions, transfers owned documents, removes privileged group membership, and records completion in the service desk.

At 15:30, a manager writes in chat: "Their last meeting is done. Offboard them now."

An MCP client can discover the relevant tools and call them with valid arguments. That does not establish whether the manager can change the effective termination time, whether a legal hold blocks document transfer, whether payroll has finalized the status, or whether disabling the account before the HR event violates policy. The connection can work exactly as designed while the business action is wrong.

MCP standardizes how an AI application exchanges context with servers and invokes capabilities. Governance begins where that interoperability stops: deciding which work is authorized, under which conditions, with what evidence, and who remains accountable when execution becomes partial or ambiguous.

A valid tool call can still be the wrong action

The MCP tool model gives a server a clean way to publish a name, description, input schema, and optional output schema. A client can discover those definitions through tools/list and execute one through tools/call. The MCP tools specification also places important responsibilities around that exchange: servers should validate inputs, enforce access controls, rate-limit calls, and sanitize outputs; clients should confirm sensitive operations, validate results, apply timeouts, and log usage.

Those are necessary controls. They still operate at a different level from the offboarding decision.

An input schema can require employee_id, effective_at, and reason. It cannot determine that the HR record, rather than a chat message, is authoritative for effective_at. A successful authorization flow can prove that a client obtained a token intended for the MCP server. It does not prove that the person who initiated the workflow owns the employment decision. A confirmation dialog can show disable_user, but it may not show that document transfer will break an active legal hold or that the same task has already been executed by another run.

Protocol validity answers whether the message is well formed and the capability is available. Business validity depends on facts and decisions outside the protocol:

• which source controls the employee's current status;
• which identity requested the work and which identity will execute it;
• what policy version applies in the employee's country and employment class;
• whether the workflow is early, duplicated, cancelled, or superseded;
• which actions require a named approver;
• what must happen before a destructive step; and
• what evidence will establish completion.

If these conditions exist only in a system prompt, the control is advisory. They need to be enforced in the execution path.

Transport authorization is narrower than workflow authority

The distinction becomes clearer when identity is separated into roles.

The requester is the person or system that initiated the offboarding. The actor is the workload identity used to call the target system. The subject is the employee whose access will change. The approver supplies authority for decisions that the requester or actor cannot make alone. The accountable owner is responsible for the outcome after the run ends.

OAuth can participate in this model without replacing it. The MCP authorization specification defines authorization for HTTP-based transports and requires tokens to be bound to their intended MCP resource. When an MCP server calls a downstream API, the specification requires a separate downstream token rather than forwarding the client's token. The accompanying security guidance explains why token passthrough weakens control and attribution.

That protects an important boundary: a token issued for one service should not silently become a credential for another. The workflow still needs a policy decision over the action itself.

For example, a narrowly scoped offboarding service account may be allowed to revoke sessions. Whether it may do so for this employee at 15:30 depends on purpose, current HR state, timing, exceptions, and approval. The token establishes what the actor can technically request. Workflow authority establishes what this run may do now.

Using the requester's token creates a different problem. A manager with broad directory access may unintentionally give the agent more reach than the offboarding task requires. A manager with limited access may cause the same workflow to fail halfway through. Both cases make execution depend on the requester's ambient privileges instead of a stable, reviewed action boundary.

MCP does not require that design. It also does not repair it.

The runtime needs an execution envelope

Before a sensitive tool call, the runtime should be able to produce a compact record that explains why the call is permitted. This is not another prompt. It is structured state assembled from authoritative records and policy decisions.

An illustrative execution envelope for the account suspension might contain:

task_id: OFF-2048
purpose: scheduled_employee_offboarding
requester: manager:1842
actor: workload:offboarding-agent-prod
subject: employee:7721
authoritative_event: hris:termination:99108
policy_version: access-offboarding@2026-07-15
decision: allow
allowed_action: identity.disable_sign_in
execute_after: 2026-08-04T17:00:00+07:00
approval_ref: hr-approval:5519
idempotency_key: OFF-2048:disable-sign-in
evidence_refs:
  - hris:employee:7721@version-44
  - idp:user:8fd2@observed-16:59:52

Each field closes a specific gap. purpose prevents a general integration from becoming a general entitlement. authoritative_event ties the action to the HR decision instead of the latest message in chat. policy_version makes the decision reproducible after policy changes. execute_after keeps planning separate from execution time. The idempotency key gives the target service a way to recognize a duplicate request. Evidence references preserve the records used without injecting full documents into model context.

The envelope should be generated as late as practical. A plan approved at 15:30 can be stale at 17:00. The termination may have been rescinded, an investigation may have placed the account on hold, or the employee may have moved into a different process. Rechecking authority at execution is not wasted work; it closes the time between a valid plan and a no-longer-valid action.

This is also where tool exposure should narrow. The MCP architecture assigns the host responsibility for connection permissions, security policy, consent, and context aggregation. A production host does not need to expose every connected tool to every run. It can construct a task-specific registry containing the capabilities allowed for the current workflow stage, then require a fresh decision before adding a higher-impact action.

Tool discovery becomes safer when it follows authority instead of preceding it.

Human approval belongs at the consequence boundary

The tools specification recommends a human in the loop with the ability to deny invocations, while leaving the interaction model to the implementation. A confirmation dialog for every read and write is one implementation. It is rarely a workable operating model.

In the offboarding workflow, asking a person to approve each directory lookup, group read, and session query turns the agent into a slow remote control. Asking once at the beginning to "complete offboarding" hides too much. The approval should sit where human judgment changes the consequence.

A reviewer might approve a proposed action set containing the effective time, accounts affected, ownership transfers, exceptions, and irreversible steps. The runtime can then execute read-only checks and reversible actions inside that approved boundary. It should return when the observed state changes the proposal, when an action exceeds the approved scope, or when an irreversible step is ready.

Approval must bind to the proposed payload, not only to a tool name. Approving transfer_documents without the source owner, destination owner, document set, exclusions, and retention policy leaves the material decision unresolved. If those inputs change after approval, the approval should no longer authorize the call.

This introduces friction. Preparing reviewable payloads, retaining approvals, and re-requesting approval after material changes takes time. It also prevents the operating team from treating a click on a generic consent screen as evidence that someone accepted a specific business consequence.

A protocol call is not a cross-system transaction

Offboarding is a sequence, not one API request. Suppose sign-in is disabled, active sessions are revoked, and privileged groups are removed. The document transfer then fails because the destination owner lacks capacity. The service-desk update times out after it may have committed.

The workflow is neither complete nor safely restartable from the beginning.

MCP can carry tool results and distinguish protocol errors from tool execution errors. The server can return structured status, and the client can use that result to continue. It cannot make independent HR, identity, storage, and ticketing systems participate in one atomic transaction.

The runtime has to retain a state machine outside the conversation:

• which actions were planned, approved, attempted, and observed as committed;
• which calls are safe to retry and which require a status lookup;
• which records changed between attempts;
• which compensating action is available;
• which incomplete state is acceptable for a limited period; and
• who owns the exception when automation cannot establish the outcome.

An HTTP timeout is especially awkward. It says the caller did not receive a response. It does not say the target system rejected the change. Retrying disable_sign_in may be harmless if the operation is idempotent. Retrying a document transfer or notification may duplicate side effects. A governed runtime needs tool-specific failure semantics and a reconciliation path, not a generic retry counter.

This control belongs partly in the tool server and partly above it. The server is closest to the downstream API and should return stable record identifiers, commit status, retry guidance, and sanitized error details. The workflow runtime is the only component with enough cross-system state to decide whether the business process can continue.

Governance is distributed; the evidence must join it back together

There is no single component that can enforce the whole offboarding policy.

The MCP host controls which servers and tools enter the model's action surface. The workflow runtime owns task state, sequencing, policy decisions, approvals, and recovery. Each MCP server validates inputs, limits access, protects credentials, and translates downstream failures. The target system remains the final authority over its records and should retain its own audit event. Human owners decide exceptions that policy cannot resolve.

Because control is distributed, the evidence has to share identifiers. A useful run record should connect the original request, task ID, agent release, policy decision, approval, MCP server and tool, exact arguments or a protected digest, downstream record ID, result, and subsequent reconciliation. Without that chain, every component can have a log while the organization still cannot explain what happened.

The Coryntas integrations approach treats a connection as part of a workflow contract: inputs, outputs, identity, side effects, failure behavior, and evidence are designed around the work the agent must complete. MCP can implement the interoperable tool boundary inside that contract. The security and governance path and the agent harness carry the decisions and state that the protocol intentionally leaves to the host and runtime.

This additional machinery has a real cost. Policy evaluation adds latency. Narrow tool exposure reduces flexibility. Evidence retention creates storage and privacy obligations. Reconciliation workers and exception queues require operating owners. A low-risk, read-only assistant may not need the same controls as an offboarding agent, and forcing both through one process can make the simple system needlessly heavy.

The boundary should follow consequence. As an agent moves from retrieving information to changing a business system, protocol interoperability becomes more valuable—and less sufficient on its own.

MCP can tell the application how to call the tool. The workflow runtime and operating team must still establish why this task may call it, what happens if the call only partly succeeds, and who can account for the result.