# How outside leadership governs MCP production access

> A practical framework for MCP production access using scoped credentials, exact approvals, audit evidence, tested rollback, and named ownership.

Giving an agent a production endpoint does not make it production ready. Production access means the agent can spend authority: read customer data, change infrastructure, merge code, send messages, or trigger a payment. The decision belongs to the person who owns the resulting incident, not to the engineer who got the demo working.

You should hire outside AI leadership before granting that access when nobody inside can define the boundary, name the approver, prove what happened, and stop the system safely. Do not hire an adviser merely to bless a launch. Give an interim leader authority to set gates, reject exceptions, assign owners, and leave behind an operating system your team can run.

The bar is evidence, not confidence. I use five gates: credential isolation, risk-based approvals, reconstructable audit logs, tested rollback, and named human ownership. An agent that fails any one of them stays in a sandbox or gets read-only access.

## Production access is a grant of authority

MCP production access should be classified by possible effect, not by server location. A tool connected to a production database with read-only credentials can expose private data. A tool running in a test cluster can still create a production incident if it holds a cloud administrator token. The environment label tells you where code runs; the credential and tool contract tell you what it can do.

Build an authority inventory before discussing autonomy. For each MCP tool, record the resource, allowed actions, credential identity, maximum scope, data class, approval rule, rate limit, and owner. Treat every tool call as an action by a principal, even when the model chose the action. If you cannot put a stable identity behind a call, you cannot investigate it or revoke it cleanly.

I separate tools into four effect classes:

- Observe: read non-sensitive operational state without changing it.
- Sensitive read: access customer, employee, financial, security, or proprietary data.
- Reversible write: change state that a tested compensating action can restore.
- Irreversible or externally binding: delete data, rotate shared credentials, publish, pay, notify customers, or alter access control.

This classification prevents a common argument: "The agent only calls an API." APIs are where authority is exercised. A ticket lookup and an account deletion may share the same transport, but they do not deserve the same credential, approval flow, or rollout gate.

Do not grant a bundle called "production access." Grant a short list of tool and resource pairs. Default everything else to denied. A new tool, broader scope, or new data class is a fresh access decision, not a small configuration change.

Inventory indirect effects as well. A tool that edits a deployment manifest may not call the cloud control plane, but the continuous delivery system will act on its change. A tool that writes to a support ticket may trigger an automation rule that emails a customer. Trace these chains until you reach the actual business effect, then classify the first tool by the strongest reachable effect.

Include cost and volume in the grant. An agent with permission to make one harmless API call can still cause an outage or a large bill by repeating it. Put per-call, per-task, and per-time-window limits close to the resource. Rate limits at the model provider do not constrain calls made with a downstream credential.

## Hire outside leadership when ownership is missing

Outside leadership is justified when the company lacks an internal person who can make cross-functional risk decisions and remain accountable after launch. The work crosses engineering, security, operations, legal obligations, and product behavior. A vendor who only configures an MCP server cannot settle those tradeoffs.

Use four tests. If two or more fail, appoint an internal leader with enough authority or bring in a fractional CTO or equivalent operator before production access:

1. Can one named executive accept or reject the residual risk?
2. Can one technical owner trace an agent action across the host, MCP server, and downstream system?
3. Can an on-call engineer revoke access and contain damage without finding the original developer?
4. Can the business owner explain which actions require a human decision and why?

An external leader earns the role by producing decisions and working controls. The useful deliverables are an authority inventory, a risk classification, an approval matrix, a log contract, an incident runbook, and an exit plan that transfers ownership. A slide deck about responsible AI does not reduce production risk.

Do not outsource accountability to the consultant. Your executive still accepts business risk, and your staff still operate the system. The outside leader temporarily closes an experience or capacity gap, runs the hard review meetings, and makes sure every control has an owner. Their engagement should end or shrink once an internal owner can run access reviews, incident exercises, and gate changes without them.

There is also a case for proceeding without outside help. If your security and platform leads already own service identities, policy enforcement, audit pipelines, and incident response, let them govern the agent. Add specialist review for a novel threat model if needed. Hiring another leader then adds a meeting layer and blurs responsibility.

Interview outside candidates against your actual workflow. Give them a proposed tool list and ask which capability they would refuse first, what evidence could change that decision, and who must own the exception. A credible operator asks about authority paths, downstream side effects, identity boundaries, and response duties. Someone who begins with model selection or prompt quality is solving the wrong layer of the production problem.

Set access to evidence in the engagement. The leader needs architecture, identity policy, representative logs, incident procedures, tool schemas, and interviews with the people who operate the affected systems. They should not need broad production credentials to inspect governance. If implementation requires temporary access, issue a named, limited identity and review it like any other production grant.

## Credentials must identify the agent and constrain it

The credential gate passes only when the agent has its own identity, the token is limited to intended resources and actions, secrets stay out of model context, and revocation works quickly. Reusing a developer token or a broad service account fails the gate even if the first workflow is read-only.

The MCP Authorization specification makes two points teams routinely soften into suggestions. An MCP server must validate that a token was issued for that server, and it must not pass the client's token through to a downstream API. This is audience binding, not token presence. A valid token presented to the wrong resource is still the wrong token.

That distinction matters because token passthrough erases boundaries. The downstream service may record the wrong actor, the MCP server cannot apply its own policy reliably, and a stolen token may work across services. The MCP server should act as a resource server for the client and as a separate OAuth client for the downstream API. Each hop gets a token intended for that hop.

Your negative test should look like this:

```bash
curl -i https://mcp.internal.example/tools \n  -H "Authorization: Bearer $TOKEN_FOR_BILLING_API" \n  -H "Content-Type: application/json" \n  -d '{"name":"deploy_service","arguments":{"service":"catalog","version":"2026.07.4"}}'
```

The expected shape is a rejection before tool dispatch:

```text
HTTP/1.1 401 Unauthorized
Content-Type: application/json

{"error":"invalid_token","error_description":"audience mismatch"}
```

Run the same test with an expired token, a token for another tenant, a token missing the tool scope, and a revoked agent identity. Verify the downstream API receives no request. A client-side error message does not prove server-side enforcement.

Keep access tokens short lived, rotate refresh tokens where the authorization model supports them, and store credentials in a secret manager available to the MCP server, not in prompts, tool descriptions, repository files, or chat transcripts. Scope by tool and resource where practical. "All repositories" is not a useful scope when the agent deploys one service.

## Tool contracts must survive hostile input

Credential controls limit available authority, but they do not tell the agent when using that authority is appropriate. The tool contract and policy layer must treat model output, retrieved documents, issue text, emails, web pages, and downstream tool results as untrusted input. Any of them can contain instructions that conflict with the user's request.

This is where teams blur prompt injection and authorization. Prompt injection influences what the model proposes. Authorization determines what the system permits. You should reduce injection success with clear instruction boundaries and content handling, but production safety cannot depend on the model consistently recognizing hostile text. Enforce resource, action, tenant, and effect limits outside the model.

Write narrow tool schemas. `run_command(command)` hands policy an arbitrary string after the model has already decided what it means. `restart_service(service_id, environment)` gives the policy engine typed fields it can validate. An unconstrained SQL tool, shell tool, browser session, or generic HTTP request deserves the strongest effect class reachable through it, not the safest task you intend to run today.

Descriptions also need review. An MCP tool description affects model selection and arguments, so a changed description can alter behavior without changing executable code. Version the name, description, input schema, output schema, and effect class together. Reject unknown fields, constrain values server-side, set payload and response limits, and return structured errors that do not expose secrets or internal instructions.

Test with adversarial content placed at every trust boundary. Put a fake instruction in a ticket title, a retrieved document, a tool error, and an API field that the model will summarize. Ask it to ignore the user, select a broader tool, reveal a secret, or change the target. The expected result is not merely a polite refusal from the model. The policy layer must reject any call outside the user's authority and the approved task.

Tool discovery creates another change path. If the host accepts newly advertised tools automatically, a compromised or misconfigured server can expand the model's choices after review. Pin the approved server identity and tool catalog in production, or require a gate review when discovery returns an unknown or changed schema. Alert on catalog drift.

For third-party MCP servers, ask for more than a security questionnaire. Require the supported authorization flow, token audience behavior, scope model, data retention, log export shape, change notification process, vulnerability reporting channel, and a practical revocation test. Confirm whether the server calls other services and which identity appears in those downstream logs. If the provider cannot explain the credential chain, do not connect it to production authority.

Run third-party servers behind an egress policy where possible. Allow only required destinations and block cloud metadata endpoints, internal address ranges, and arbitrary redirects unless the workflow needs them. A narrow token does not prevent a server from sending data to an unintended network destination.

This gate does not require a perfect model. It requires a small, reviewable action surface whose hard limits remain true when the model makes a bad decision or consumes malicious content.

## Approval must attach to the exact action

An approval gate passes when a human sees the action's material effect, the target, and the relevant parameters before a risky call executes. A blanket approval at session start is consent to use the agent, not approval for every consequence the agent may later propose.

Approval policy should follow effect class. Ordinary observation can run automatically within rate and data limits. Sensitive reads may require a business purpose, masking, or a user with matching access. Reversible writes need approval until the workflow has a measured history and a reliable compensating action. Irreversible or externally binding actions keep human approval unless an executive accepts a narrowly defined exception.

Bind the approval to a digest of the proposed call. The approved object should include the agent identity, tool name, normalized arguments, target resource, requesting user, timestamp, expiry, and policy version. If any material argument changes, invalidate the approval. Otherwise an agent can ask permission to deploy one version and execute another.

The approver needs a plain effect preview. "Run `update_record`?" is useless. "Change the billing contact for account 1842 from finance@example.test to ops@example.test" gives the person a decision. For bulk actions, show count, selection rule, excluded records, and the maximum possible effect.

Avoid adding approval prompts to every call. That trains people to click through and turns the human into latency. Use policy to stop high-effect transitions, aggregate predictable low-risk reads, and place limits below the approval layer. A person should never be asked to approve an operation that a hard policy should forbid, such as crossing tenant boundaries or using a credential outside its audience.

Test approval bypasses deliberately. Replay an approval, change one argument after approval, submit it after expiry, call the tool directly without the agent host, and race two executions against one approval. The expected result is one authorized action and explicit denials for the rest.

Decide what happens when the approval service is unavailable. High-effect actions should fail closed. Low-effect observation may continue under a cached policy if the business owner accepts that mode and the cache has a short expiry. Record degraded operation as an audit event and page the control owner before users learn to route around it.

Approver authority also needs scope. A release manager for one service should not approve an identity change across the company. Derive approval rights from the target and effect class, require stronger separation for actions that change access controls, and prevent a requester from approving their own high-effect proposal.

## Audit logs must reconstruct the decision

The logging gate passes when an investigator can answer who requested an action, which agent and policy handled it, what tool ran, what the downstream system changed, who approved it, and whether rollback succeeded. Application logs that say "tool completed" do not meet that standard.

OWASP's MCP guidance calls for logs across tool invocations, user context, and timestamps. I would qualify "full parameters": record enough to reconstruct the action, but never dump credentials, raw authorization headers, or sensitive payloads into the log pipeline. Store redacted parameters plus a deterministic digest when the original values belong in a restricted system of record.

Define a log contract before launch. A useful event has a stable shape:

```json
{"event":"mcp.tool.completed","trace_id":"tr_7f2","agent_id":"release-agent","requester_id":"user_418","tool":"deploy_service","target":"catalog","arguments_digest":"sha256:8c1...","policy_version":"prod-12","approval_id":"ap_992","result":"success","downstream_request_id":"req_61a","occurred_at":"2026-07-27T14:03:19Z"}
```

Emit events at proposal, policy decision, approval, dispatch, downstream result, and rollback. Use one trace identifier across the host, MCP server, policy service, and downstream adapter. Keep the agent's free-form reasoning separate from the audit record. Reasoning text can contain private data, change between model versions, and still fail to explain which policy allowed the call.

Protect logs from the agent's write path. The identity that performs a deployment should not be able to edit or delete its audit events. Set retention from incident, contractual, and legal needs rather than copying a default. Alert on denied high-effect calls, repeated approval failures, missing event stages, unexpected scope use, and sudden drops in event volume.

Before production, choose a test trace and ask an engineer who did not build the workflow to reconstruct it. They should find the requesting human, exact approved action, policy version, downstream confirmation, and final state. If they need to ask the developer what a field means, the log contract is unfinished.

## Rollback is a tested business operation

The rollback gate passes when the on-call team can stop new actions, revoke authority, contain affected resources, and restore an acceptable state within a declared time. "We can redeploy the previous code" covers only one part of an agent incident.

Use two separate controls. A kill switch prevents new tool dispatch at the MCP policy boundary. Credential revocation removes the agent's authority even if another path reaches the server. Test both because a feature flag may depend on the same control plane that is failing, while revocation may take time to reach caches.

For each write tool, define a compensating action and its limit. Reverting a deployment is usually feasible. Recalling an email, undoing a payment, or making exposed data secret again is not. Label those actions irreversible and move approval earlier. Do not call an operation reversible merely because the API exposes a DELETE method.

The runbook should state:

- Who can disable the agent and revoke each credential.
- Which queues, scheduled tasks, sessions, and retries must be drained.
- How responders identify affected resources from trace identifiers.
- Which state can be restored automatically and which needs manual repair.
- Who decides when access returns and at what reduced scope.

Exercise a realistic failure. Inject a tool response that causes the agent to propose the wrong deployment target. Let policy or approval stop it first. Then assume that control failed, dispatch into a safe test resource, trigger the kill switch, revoke the identity, drain retries, restore state, and verify the audit chain. Time the steps, but do not invent a universal recovery target. A deployment agent and a payment agent carry different damage clocks.

Rollback also includes the model and configuration. Pin the model version where your provider permits it, version prompts and tool schemas, and retain the policy version on every event. If a behavior change appears after an update, you need a known configuration to restore, not a debate about whether the model feels different.

## Human ownership cannot be shared by a committee

The ownership gate passes when named people hold four distinct duties: business risk acceptance, technical operation, security policy, and approval for each high-effect action. One person can hold more than one duty in a small company, but every duty needs a name and a backup.

Write ownership beside the tool, not in a general AI policy. The customer-support lead may own the effect of issuing refunds, while the platform lead owns the MCP server and the security lead owns credential policy. An "AI council" can review patterns, but it cannot take an incident call or approve a specific refund at 2 a.m.

The business owner defines acceptable outcomes and forbidden effects. The technical owner maintains the server, adapters, tests, and telemetry. The security owner controls identities, scope, policy, and exceptions. The action approver judges the proposed change in context. The incident commander can suspend all four when evidence suggests harm.

Every exception needs an owner, expiry, and removal condition. Teams often grant a broad token "for the pilot" and discover months later that no one knows whether narrowing it will break a workflow. Put temporary scope in policy as an expiring exception and alert before it ends. Renewal should require evidence, not silence.

Outside leadership fits here when the boxes are empty or the named people lack authority. A Team & AI Audit at oleg.is can identify the missing controls and economic case in five business days; fractional CTO leadership makes sense when someone must implement the operating model and run it month to month. Neither service should become the permanent approver for your production actions.

Ownership has an exit test. Ask the internal technical owner to run an access review, explain one trace, execute the rollback exercise, and reject an unjustified exception without the outside leader. If they can do all four, transfer the decision calendar and incident role.

## A staged rollout must earn broader access

A safe rollout expands one effect at a time and requires evidence at each gate. Do not start with a fully capable agent behind many approval dialogs. That creates a large attack surface before you know whether the controls describe reality.

Stage zero runs recorded or synthetic requests with no network credentials. Validate tool schemas, argument constraints, redaction, and policy decisions. Include hostile content in tool results and retrieved documents, because an agent may treat untrusted text as instructions.

Stage one grants observation on a narrow resource set. The exit evidence is complete traces, correct tenant isolation, stable rate limits, and successful revocation. Stage two allows a reversible write in a test target, then a production target with per-action approval. The exit evidence adds approval binding and a completed rollback exercise.

Stage three may automate a narrow reversible action. Set a small maximum effect per execution and per time window, retain anomaly alerts, and keep the kill switch. Irreversible actions remain separately approved unless your risk owner documents why automation is acceptable and what compensating business process exists.

Use a gate record for every expansion:

```yaml
capability: deploy catalog service
effect_class: reversible_write
resources: [production/catalog]
agent_identity: release-agent
required_scope: deploy:catalog
approval: release-manager-per-execution
max_effect: one deployment
rollback_test: passed-2026-07-24
log_trace_review: passed-tr_7f2
business_owner: head-of-product
technical_owner: platform-lead
security_owner: security-lead
decision: approved
```

The values above are an example, not a universal policy. Your record should link a grant to test evidence and named owners. When the tool schema, resource, credential, approval rule, model behavior, or downstream API changes materially, reopen the gate.

Measure control performance rather than model charm. Track unauthorized calls blocked, approvals changed or rejected, incomplete traces, rollback exercise failures, scope exceptions, and incidents by effect class. A high task-completion score cannot offset missing evidence about authority.

## The launch decision should be boring

The final decision is mechanical: grant only the capabilities whose five gates pass, keep failed capabilities read-only or sandboxed, and record who accepted the remaining risk. If the meeting depends on assurances that the agent is "usually careful," the system is not ready.

Hire outside AI leadership when nobody internal can drive that process across teams or when the cost of learning during production exceeds the engagement. Define the mandate before signing: produce the authority inventory, implement or assign the controls, run the exercises, chair the launch decision, and transfer ownership. Do not pay for vague oversight.

Delay outside hiring when your existing leaders can show the same evidence and have time to operate it. Spend the money on the missing engineering work. Conversely, do not ask a strong application engineer to accept company-wide security and business risk without executive authority. That is a governance failure disguised as empowerment.

At the gate review, inspect artifacts in this order: scoped identity and negative credential tests, approval binding and bypass tests, a reconstructed trace, a completed rollback exercise, then named owners and exceptions. Any missing artifact produces a limited grant or a rejection. Schedule the next review around a concrete remediation, not around pressure to launch.

Production access is earned capability by capability. The useful leader, internal or external, makes that sentence operational and leaves the company able to enforce it after they step away.