Secure MCP for Coding Agents Across Laptops and CI

The verdict: one MCP endpoint, two security lanes

The same MCP server can serve engineers and automation, but it should never collapse them into the same principal. A laptop request answers "which person is acting?" A CI request answers "which repository, workflow, revision, environment, and run is acting?" The policy engine evaluates those identities differently even when both request tools/call.

That distinction is now easier to enforce at the protocol boundary. MCP 2026-07-28 is stateless, and a server must not infer client identity or other context from earlier requests on the same connection. io.modelcontextprotocol/clientInfo and io.modelcontextprotocol/serverInfo are self-reported, are not verified by MCP, and should not be used for security decisions. Identity therefore comes from a validated credential on each request, not a process name, a model claim, a tool argument, or an open connection. The current MCP core specification states all three constraints directly.

This is the operating model. The broader MCP security controls still apply, but the laptop and CI lanes should remain separate from sign-in through audit receipt.

Propagate identity without passing tokens through

Carry the principal across the system, but mint a new credential at every audience boundary. Forwarding one broad bearer token through the MCP server is not identity propagation. It is credential reuse across trust domains.

On laptops, use interactive authorization for the human

For a remote HTTP server, use the core MCP authorization flow so the client acts for a resource owner. The MCP HTTP authorization framework is based on OAuth 2.1 and makes the MCP server an OAuth resource server and the MCP client an OAuth client acting for a resource owner. MCP clients must include the RFC 8707 resource parameter in authorization and token requests, and MCP servers must validate that access tokens were issued for them as the intended audience. Those are normative requirements in MCP authorization.

The server should derive the human identity from the validated MCP credential, using an authoritative sub claim when available. The token's audience is the MCP server, and its scopes cover only the starting tool set. MCP clients must implement PKCE, verify authorization-server support, and use the S256 method when technically capable. Authorization servers should issue short-lived access tokens, and public clients must rotate refresh tokens. MCP's authorization security considerations define these protections.

Local stdio needs a more explicit boundary because there is no HTTP resource-server flow to lean on. The stdio transport launches the MCP server as a subprocess, while the current authorization specification says stdio implementations should retrieve credentials from the environment instead of using the HTTP authorization flow. The stdio binding documents the child-process model. For a privileged company integration, we would expose a remote, authenticated MCP endpoint or launch the local server with a deliberately constructed environment containing only a broker handle. We would not give every stdio server the engineer's full shell environment.

In CI, authenticate the workload rather than impersonating a developer

For headless automation, use a machine principal. The official io.modelcontextprotocol/oauth-client-credentials extension is intended for machine-to-machine access including CI/CD pipelines. It supports a client secret or a signed JWT assertion and recommends JWT bearer assertions. Support for MCP authorization extensions varies by client; extensions are opt-in and never active by default, so compatibility belongs in the admission test for a CI client. The official extension documents the flow and its support constraint.

GitHub Actions can supply the upstream workload proof without a repository secret. GitHub Actions OIDC tokens contain issuer, audience, subject, repository, repository ID, workflow reference and SHA, environment, actor, run ID, and runner-environment claims that can be used in workload trust conditions. GitHub Actions id-token: write permits a job to request an OIDC JWT but does not itself grant write access to other resources. GitHub's OIDC reference lists the claims and permission semantics.

The clean sequence is:

1. The job requests an OIDC assertion with an audience for your authorization service.
2. The authorization service validates the issuer, audience, repository identity, workflow identity, revision or ref policy, environment, and run context.
3. The authorization service issues an MCP access token for the MCP server audience and the job's permitted scopes.
4. The MCP server validates that token again on each request.

If your identity platform implements token exchange, RFC 8693 token exchange allows a resource server to trade an inbound token for a new token appropriate for a backend service; subject_token identifies the party on whose behalf a request is made and optional actor_token identifies the acting party. RFC 8693 also lets a token-exchange request specify target resource or audience and desired scope. The RFC defines the exchange and delegation fields. This is how you preserve an accountable workload subject while reducing the token to the audience and permissions of the next hop.

At downstream APIs, exchange or reconnect

The inbound MCP token stops at the MCP server. An MCP server calling an upstream API must use a separate token issued for that API and must not pass through the token received from the MCP client. The prohibition is explicit in the current MCP authorization security requirements.

For an internal API under the same identity system, exchange the MCP token for a narrower downstream token. For a third-party service such as GitHub, let the MCP server complete a separate user authorization and store the resulting token against the authoritative user subject. Do not ask the coding agent to paste a personal access token into a prompt or tool argument.

Make least privilege visible in the tool catalog

Least privilege should change what the model can discover, not only what a hidden middleware check later rejects. An MCP server's tools/list result may vary according to the authorization on the request, including returning only tools permitted by the caller's scopes. MCP 2026-07-28 explicitly permits authorization-filtered tool discovery.

Start with a small capability vocabulary tied to business effects:

• repo:read exposes search, file read, dependency inspection, and diff retrieval.
• change:propose creates a patch or pull-request draft but cannot publish it.
• repo:write can create a branch or update an existing change.
• release:write can mutate a release or deployment target and always needs a separate gate.
• admin is never granted to a general coding-agent lane.

Those names are an illustrative policy, not protocol-defined scopes. The important part is that the same policy controls token issuance, tool discovery, and tool execution. A practical server policy can be expressed like this:

default: deny

principals:
  developer:
    identity_source: oauth_subject
  ci:
    identity_source: workload_subject

tools:
  repo.search:
    scopes: [repo:read]
    principals: [developer, ci]
  change.propose:
    scopes: [change:propose]
    principals: [developer, ci]
  branch.write:
    scopes: [repo:write]
    principals: [developer]
    approval: per_call
  release.publish:
    scopes: [release:write]
    principals: [ci]
    approval: protected_executor

Filter tools/list, then authorize tools/call again against the validated principal, requested tool, arguments, target resource, environment, and current policy version. Discovery is a usability control; execution authorization is the security control. MCP servers must validate tool inputs, implement access controls, rate-limit tool calls, and sanitize outputs. Those are server requirements in the tools specification.

Do not turn tool annotations into permissions. MCP clients must treat tool annotations as untrusted unless they come from trusted servers. A readOnly-style description can improve a confirmation screen, but it cannot overrule policy or prove that an implementation has no side effect. The server authorizes observed identity and requested effect, not descriptive metadata.

For a human, a denied write can trigger scope step-up. MCP clients should request only scopes needed for the intended operation, and the current authorization specification supports incremental step-up after an insufficient_scope response. The scope-selection and step-up rules are documented in the authorization specification. For CI, missing scope should usually terminate the job. A headless agent should not silently broaden itself because a tool asked for more power.

Put approval before credential release

The strongest approval gate is the one that controls whether the executor ever receives write authority. A prompt that appears after a broad token is already present on the runner is useful UX, but it is not a secret boundary.

MCP clients should show tool inputs before a call, request confirmation on sensitive operations, and log tool usage for audit purposes. The tools specification makes those client responsibilities explicit. On a developer laptop, the confirmation should name the server, tool, repository or service, target branch or environment, and normalized arguments. Approval applies to that proposal only. If the arguments change, ask again.

In CI, use a planner-executor split:

GitHub environment protection rules can require reviewers and prevent self-review, and environment secrets remain unavailable to a job until the configured protection rules pass. GitHub documents both the review control and secret-release timing. This makes a protected environment a useful outer gate for a privileged MCP executor. It does not bind approval to a particular tool call by itself, so the executor still needs to compare the approved manifest with the call it is about to make.

Keep untrusted code out of that executor. GitHub documents that pull_request_target jobs have elevated trust and that executing pull-request-controlled code in that context can expose repository secrets and tokens. GitHub's secure-use reference shows the vulnerable workflow shape. Inspect untrusted pull-request content in the planner as data. Run the privileged executor from trusted workflow code, on isolated compute, against the approved manifest.

Draw a secret boundary the model cannot cross

Secrets should enter at an identity or credential broker and leave only as a scoped call, never as model-visible text. That rule matters on both developer machines and runners.

On laptops, launch stdio servers with an allowlisted environment rather than inheriting the whole shell. Give a local process a broker socket, OS credential-store reference, or short-lived token for one service instead of a collection of API keys. Move privileged integrations to authenticated HTTP when central policy, revocation, and audit correlation matter more than offline convenience.

On CI, assume that code running on the runner can read every credential available to that job. GitHub documents that a compromised runner can read secrets placed in environment variables, referenced secrets can be harvested, and log redaction is not a security boundary against intentional exfiltration. The compromised-runner guide describes these paths. This is why the planning job gets no write secret and why the executor should use short-lived workload credentials on isolated, disposable compute.

MCP itself now supplies a clean path for third-party secrets. MCP form-mode elicitation must not request passwords, API keys, access tokens, or payment credentials; URL mode is required for sensitive interactions. In the MCP external-authorization pattern, third-party credentials must not transit through the MCP client, the server must not use the client's third-party credential, and the server stores a distinct downstream token bound to the user. The elicitation specification defines this boundary.

That produces three hard rules:

• Never put a secret in a prompt, MCP tool argument, tool result, approval manifest, trace attribute, or audit payload.
• Never let the laptop token become the CI token, or the MCP token become the downstream API token.
• Never release a write credential to code that has not crossed the relevant trust and approval boundary.

Build an audit trail that survives both lanes

Audit events should explain the authorization decision and the effect, while traces explain the execution path. Keep both, correlate them, and do not treat debug logs as an approval ledger.

MCP reserves traceparent, tracestate, and baggage in _meta for OpenTelemetry propagation, and their values must follow W3C Trace Context and W3C Baggage formats. The current core specification defines the propagation fields. Propagate that context from the coding-agent host through the MCP server and downstream API. Then write a separate security event at the authorization point.

Use a stable event shape like this, with values shown only as examples:

{
  "event": "mcp.tool.decision",
  "principal_kind": "workload",
  "principal_subject": "validated-subject",
  "workload": {
    "repository_id": "validated-repository",
    "workflow_sha": "validated-workflow-revision",
    "run_id": "validated-run"
  },
  "mcp": {
    "server": "source-control",
    "tool": "release.publish",
    "arguments_digest": "digest-of-redacted-normalized-arguments"
  },
  "authorization": {
    "decision": "allow",
    "scopes": ["release:write"],
    "policy_version": "deployed-policy-revision",
    "approval_id": "external-approval-record"
  },
  "downstream": {
    "audience": "target-api",
    "credential_subject": "brokered-subject",
    "result_id": "provider-change-record"
  },
  "trace_id": "w3c-trace-id",
  "outcome": "success"
}

For laptop requests, replace the workload claims with the validated human subject and client registration. For denied calls, record the same intent and the policy reason. Store a digest or redacted normalized argument set, not raw credentials or sensitive source text. Record the server and policy revision so a later reviewer can reproduce which rule was active.

Join external approval evidence rather than paraphrasing it. GitHub organization audit logs include workflow-job approval and rejection events with actor, timestamp, repository, request ID, run number, and workflow run ID fields. GitHub publishes the event names and fields. Preserve the workflow run ID and approval event identifier in the MCP decision event. That gives an engineering lead one chain from workload claim, to approved intent, to tool call, to downstream effect.

The acceptance test is simple: given a downstream change, can you determine which validated principal requested it, which policy allowed it, what a reviewer approved, which credential acted, what arguments were executed, and whether the call succeeded? If any answer comes from a model transcript alone, the audit boundary is incomplete.

Ship the controls in this order

Start with identity and denied paths. Approval UI and dashboards cannot repair a server that accepts the wrong principal or a runner that already holds the wrong secret.

Client compatibility is a release gate. If the chosen CI client does not support the client-credentials extension, do not silently fall back to a shared developer token. Put a small adapter in front of the MCP client that obtains the approved workload token, or select a client that implements the extension. The identity boundary matters more than client uniformity.

For the OAuth plumbing behind this model, the MCP authorization implementation guide covers resource metadata, audience checks, consent, and release gates in more detail.

Frequently asked questions