Model Proposes, Policy Decides: Enterprise MCP Permission & Audit Architecture

1. MCP Gives Models Capabilities, But Also Shifts the Risk Boundary

The MCP specification describes Tools as model‑controlled: the model may automatically select tools based on context and user prompts. The 2026‑07‑28 spec still states that Tools are model‑controlled, while recommending that sensitive calls retain a human‑refusal capability and that servers implement input validation, access control, rate limiting, and output sanitization.

A critical distinction must be recognized:

Model selects tool: "I think completing the task requires this action"
System authorizes: "Under the current identity, task, resource, environment, and risk conditions, this action is allowed"

The former is a reasoning result; the latter is an organizational decision. Reasoning can be probabilistic, ambiguous, and context‑dependent; authorization must have boundaries, provenance, revocability, and auditability. Letting the same model both propose an action and judge its own permission is equivalent to letting the applicant also be the approver.

2. Four Concept Pairs Enterprises Frequently Confuse

Tool Discovery ≠ Business Authorization

tools/list

tells the Client which capabilities a Server exposes, but "discovered" is only a capability catalog, not a business grant. For example, a code platform may expose repository.read, branch.create, pull_request.merge, release.publish, repository.delete. The model seeing these tools does not mean the current task may call all of them. A safer approach is to let the tool list itself shrink according to the authorization carried in the request; the latest MCP Tools spec also allows tools/list to return different tool sets per request based on authorization.

Authentication ≠ Authorization

OAuth answers "who this request represents", "which resource server the token is for", and "what scopes it carries". It cannot automatically answer:

Whether this person may modify the current project

Whether this requirement allows a production release

Whether the Agent may only access a specific tenant

Whether we are inside a change window

Whether this SQL exceeds the risk budget

Whether the responsible owner has approved

Authentication is an input to authorization, not the whole of it.

Coarse Scopes ≠ Fine‑Grained Delegation

Scopes like repo:write, db:read, deploy:prod are often too broad. Real tasks usually need binding to:

Which Requirement
Which Project
Which Repository
Which Branch
Which Tenant
Which Environment
Which Action
How much data or change volume
From when to when

A long‑lived repo:write token does not prove the Agent is allowed to modify every repository; an identity with db:read should not automatically read all customer data.

Vague Approval ≠ Effective Human‑in‑the‑Loop

If the approval screen only shows "Agent requests to call execute", humans cannot actually judge risk. Effective approval must at least convey:

Who is acting on behalf of whom

Which registered tool version will be invoked

What the parameters and target resources are

What external side effects will occur

What evidence has already passed

How to roll back on failure

Whether the grant is one‑off or valid within a defined window

Otherwise "human‑in‑the‑loop" degrades to "human clicks a button".

3. Agent Tool Calls Face More Than Mis‑operation

When an Agent reads web pages, Issues, emails, documents, or tool responses, malicious instructions can be injected into the context, steering the model to call a high‑privilege tool. Therefore, an action cannot be allowed just because the model explains "this is necessary to complete the task". OpenAI's MCP usage guide explicitly warns: remote MCP Servers can access, send data, and execute actions; malicious Servers may influence the model via hidden instructions; sensitive actions should require approval, and data sent to third‑party MCP Servers should be logged.

A tool may describe itself as "readOnly", "safe", "idempotent". But the MCP spec requires: unless from a trusted Server, the Client must treat Tool Annotations as untrusted hints. That is:

readOnlyHint=true can assist display, but cannot replace the platform's own risk registration, code review, and runtime constraints.

The MCP security guide lists Token Passthrough as an anti‑pattern: a Server must not receive a token not issued for it and forward it unchanged to a downstream system. Doing so causes:

Token Audience invalidation

Downstream cannot distinguish the real caller

Rate limiting, validation, and monitoring are bypassed

Incident responsibility chain becomes unrecoverable

A leaked token may be reused laterally

The correct direction is to verify the Audience at every hop and have a Credential Broker issue short‑lived credentials for a specific target and action, rather than stuffing the user token into the prompt or passing it across multiple systems.

Local Servers often inherit the Client process's file, network, and system permissions. An obscure launch command, dependency package, or local HTTP port can turn "install a tool" into arbitrary code execution. Therefore local Servers also need source verification, full command display, explicit consent, sandboxing, filesystem and network isolation — not default trust because they run on localhost.

4. Latest MCP Spec Gives Enterprise Gateways Better Control Points

The 2026‑07‑28 version makes the protocol core stateless; each request carries protocol version and Client info; HTTP requests must include Mcp-Method and Mcp-Name. This means Gateways, WAFs, Rate Limiters, and Policy Enforcement Points can identify earlier:

This is tools/call
Which Tool is being called
Which Client it comes from
Which MCP Server it will enter

Tool schemas can use x-mcp-header to mirror non‑sensitive raw parameters as Mcp‑Param‑* headers for gateway routing or coarse‑grained policies. The spec emphasizes that passwords, tokens, API keys, and PII must not be placed in these headers. But these capabilities only "enable control points"; they do not write business policies for the enterprise. The protocol can carry authorization; it does not decide authorization for the company.

Therefore, enterprise design must adhere to one basic principle:

Model proposes. Policy decides. Human owns the exception. System records the evidence.

The model proposes a plan; the policy system decides per request; humans only approve risks that exceed automatic policy; the platform preserves complete evidence.

Chapter 2: How an Enterprise MCP Control Plane Should Be Designed

1. Don't Let Every Agent Connect Directly to Every MCP Server

The easiest architecture is:

Agent → MCP Server → Database / Git / Cloud / SaaS

It suits personal experiments but makes unified governance hard:

Each Client stores different credentials

Each Server uses its own permission model

Tool name conflicts and version drift are hard to detect

Approval logic is scattered at the call site

Audit logs cannot link to Requirement and Agent Run

After a Server is replaced, the platform may still treat it as the original trusted capability

An enterprise architecture fits a unified control plane:

User / Requirement / Agent Run
        ↓
MCP Host / Client
        ↓
MCP Gateway (PEP)
        ↓
Policy Engine (PDP) ──────── Identity Provider
        │                    Task Context
        │                    Tool Registry
        │                    Risk Registry
        │                    Approval Service
        │                    Credential Broker
        ↓
Trusted MCP Servers
        ↓
Git / CI / Database / Cloud / SaaS / Production

All requests, decisions, approvals, credential leases, results
        ↓
Audit Ledger / Evidence Plane

This follows a core Zero Trust idea: resource access goes through a Policy Decision Point and Policy Enforcement Point, making least‑privilege decisions per request, not continuous trust because a principal once entered a network or logged in once.

2. The Control Plane Needs Eight Core Components

Identity Chain

A single user_id is insufficient to describe an Agent action. The identity chain must include:

Human Principal
    ↓ delegated by
Requirement / Task
    ↓ executed by
Agent Run
    ↓ hosted by
MCP Client
    ↓ served by
MCP Server
    ↓ acts on
Downstream Resource

Every hop needs a stable ID; natural‑language names (model name, self‑reported Server name, Tool title) are only for display, not security identity.

Tool & Server Registry

The Registry should not just store name and description; it must register:

Dimension          Example
Identity           Server ID, Tool ID, Owner
Source             Official Server, Internal Server, Third‑party Proxy
Version            Version number, code commit, image or package digest
Schema             Input/Output Schema fingerprint
Impact             read, write, delete, external communication
Data               Data classification, tenant boundaries, egress/residency requirements
Environment        local, dev, test, staging, prod
Risk               Default risk level, whether approval required
Runtime Constraints Timeout, concurrency, rate, max data volume
Status             active, quarantined, deprecated, revoked

When Tool Schema, Server digest, domain, certificate subject, or behavior baseline change, the platform must re‑evaluate rather than continue with old trust.

Policy Engine (RBAC + ABAC + Relationships)

RBAC alone cannot describe Agent scenarios. More practical is combining Role, Attribute, and Relationship:

ALLOW =
    Principal
  ∩ Delegated Task
  ∩ Registered Tool
  ∩ Target Resource
  ∩ Environment
  ∩ Time Window
  ∩ Risk Policy
  ∩ Approval State

For example, the same engineer may release to test, but that does not mean any Agent they delegate can release; the same Agent Run may modify the current requirement's repo, but not the shared infrastructure.

Gateway (PEP) Enforcement

The Policy Engine decides; the Gateway enforces. It must at least:

Validate Client, Token Audience, Issuer, and expiry

Check Mcp-Method, Mcp-Name, Server and Tool Registry

Validate full parameters against Schema, resource boundaries, and data classification

Execute Allow, Deny, Approval Required, or Dry Run

Limit concurrency, call count, data volume, cost, and time

Redact sensitive fields before writing audit

Only after allowance, fetch short‑lived credentials from Credential Broker

Associate result status with Evidence Plane

"Policy written but all Agents still bypass Gateway to connect directly to Server" equals no PEP.

Capability Grant

The article proposes introducing a Capability Grant inside the platform. It is not a core MCP protocol object, but a signable, revocable, auditable enterprise authorization object:

grant_id: grant_01J...
subject:
  user_id: user_1024
  agent_run_id: run_9381
  client_id: forgex_worker
delegation:
  requirement_id: REQ-2037
  task_attempt_id: attempt_4
capability:
  server_id: git-company
  tool_id: repository.write_file
  tool_schema_digest: sha256:...
resource:
  organization: example
  repository: payment-service
  branch: ai/REQ-2037
  environment: development
constraints:
  allowed_paths:
    - src/**
    - tests/**
  denied_paths:
    - .github/workflows/**
  max_changed_files: 20
  network_egress: none
risk:
  level: L2
  approval_required: false
validity:
  issued_at: 2026-08-17T02:00:00Z
  expires_at: 2026-08-17T04:00:00Z
  max_invocations: 60
policy:
  bundle_id: mcp-policy-2026-08-17.3
  decision_id: decision_7F...

Such a Grant is closer to real work delegation than a long‑lived repo:write scope: it states who, for which task, using which tool version, within what resource scope and time window, may do what.

Credential Broker

Agents must not read production passwords, long‑lived tokens, or cloud keys and pass them as tool parameters. The Credential Broker, after an action is approved:

Issues or exchanges short‑lived credentials for the specified Audience

Binds credentials to Tool, resource, environment, and Grant

Uses one‑time or short‑lived tokens where possible

Does not return plaintext credentials to the model context

Revokes immediately on task end, denial, timeout, or exception

Logs credential_lease_id, not the Secret itself

Structured Approval

The approval object should not be a vague "allow Agent to continue", but:

Action + Exact Target + Expected Effect
+ Diff / Preview + Verification Evidence
+ Rollback Plan + Expiration

Approving a production release must not implicitly approve a database delete; approving a specific Commit must not automatically cover a later new Commit.

Audit Ledger & Evidence Plane

Complete audit splits into at least two events:

Pre‑execution authorization decision

Post‑execution actual result

Suggested event structure:

{
  "event_id": "evt_01J...",
  "occurred_at": "2026-08-17T02:14:08.351Z",
  "principal_id": "user_1024",
  "requirement_id": "REQ-2037",
  "task_attempt_id": "attempt_4",
  "agent_run_id": "run_9381",
  "client_id": "forgex_worker",
  "server_id": "git-company",
  "tool_id": "repository.write_file",
  "tool_schema_digest": "sha256:...",
  "target": {
    "repository": "payment-service",
    "branch": "ai/REQ-2037",
    "environment": "development"
  },
  "arguments_hash": "sha256:...",
  "redacted_fields": ["content"],
  "grant_id": "grant_01J...",
  "policy_bundle_id": "mcp-policy-2026-08-17.3",
  "decision": "ALLOW",
  "decision_reason": ["TASK_BOUND", "PATH_ALLOWED"],
  "approval_id": null,
  "credential_lease_id": "lease_81...",
  "request_id": "mcp_req_72...",
  "result_status": "SUCCEEDED",
  "result_hash": "sha256:...",
  "evidence_refs": ["evidence_301", "trace_204"]
}

Logs must avoid plaintext Secrets, full PII, and unnecessary business data. For high‑value events, immutable storage, signing, hash chains, or WORM policies can strengthen tamper resistance; but "written to immutable storage" does not equal "logs are inherently correct" — identity and correlation fields must still be reliably generated at ingress.

3. Minimal Data Model

To land the concepts on a platform, at minimum the following objects are needed:

Object                Purpose
mcp_servers           Server identity, source, domain, version, trust status
mcp_tools             Tool Schema, risk, data classification, runtime constraints
policy_bundles        Versioned authorization and approval rules
capability_grants     Task‑bound, short‑lived capability authorizations
approval_requests     Approval objects, evidence, owners, validity boundaries
credential_leases     Short‑lived credential leases and revocation state, no readable Secrets
tool_invocations      Request, target, parameter summary, result, latency
audit_events          Append‑only authorization and execution fact chain
tool_attestations     Server/Tool version, digest, review, and signature info

The key is not how many tables, but whether you can trace backward from a production change to:

Production Result
→ Tool Invocation
→ Policy Decision / Approval
→ Capability Grant
→ Agent Run / Task Attempt
→ Requirement Baseline
→ Human Principal

Once this chain breaks, the platform only knows "the system changed" but cannot prove "why it was allowed to change".

Chapter 3: Make Permissions Part of the Delivery Flow, Not a Popup

1. Don't Treat All Actions Equally

The two common extremes in corporate governance are:

All Tools auto‑execute — high efficiency, uncontrolled risk

All Tools require approval — superficially safe, quickly causes approval fatigue

A more rational approach is impact‑based tiering:

Level  Typical Actions                                              Default Control
L0     Pure compute, public data read, no external side effects     Auto allow, time/quantity limited
L1     Internal read‑only, controlled repo read, test result query  Identity + task binding + data boundaries
L2     Dev branch write, test env deploy, reversible config change  Capability Grant + sandbox + auto verification
L3     Production release, external messages, customer data export, permission changes  Structured human approval + short‑lived creds + rollback ready
L4     Irreversible delete, financial actions, regulatory high‑risk ops  Two‑person review, change window, possibly prohibit direct Agent execution

The level is not decided by Tool name alone. The same execute_sql:

SELECT on a temp test DB → L1

UPDATE a reversible config on prod DB → L3

Unconditional DELETE on prod → L4 or deny

Risk calculation must simultaneously consider parameters, data classification, resource, environment, impact radius, and rollback capability.

2. Approval Should Cover a Defined Execution Envelope

To reduce repeated popups, a set of actions with clear boundaries and consistent risk can be packaged into an approval envelope:

approval_scope:
  requirement_id: REQ-2037
  release_artifact: sha256:...
  environment: production
  allowed_tools:
    - deployment.create_canary
    - deployment.read_status
    - deployment.rollback
  target_services:
    - payment-api
  max_traffic_percent: 10
  valid_for_minutes: 30
  max_executions: 1
preconditions:
  unit_test: passed
  e2e: passed
  security_gate: passed
  change_window: open
rollback:
  required: true
  artifact: release_previous

The approver signs off on a specific artifact, environment, traffic slice, and time window — not an open‑ended production pass for the Agent.

3. A Controlled Tool Invocation Should Go Through Ten Steps

1. Requirement defines goal and acceptance criteria
2. Context Builder assembles task context
3. Agent generates plan and Tool Intent
4. Risk Engine identifies resource, impact, data classification
5. Policy Engine produces ALLOW / DENY / APPROVAL_REQUIRED
6. Capability Grant and short‑lived Credential Lease take effect
7. Gateway executes Tool in sandbox or target environment
8. Runner independently verifies result and side effects
9. Audit Ledger and Evidence Plane persist the fact chain
10. Grant expires, credentials revoked, policy updated from outcome

Three critical separations:

Agent proposes action, does not issue its own Grant

Gateway executes action, does not modify Policy

Approver bears exception risk, does not replace Runner's verification

4. Must Design "Stop Capability"

Enterprises often focus on how to authorize, but neglect how to stop immediately. An operable MCP control plane also needs:

Global Kill Switch

Revoke by Server, Tool, Client, Agent Run, Tenant

Instant credential lease revocation

Tool Registry quarantine states

Automatic circuit breaker on anomalous call rates

Auto‑escalate to human review on Schema or Digest drift

Trigger rollback and block retry on production action failure

Default deny high‑risk actions when audit chain is incomplete

If an Agent is stuck in an error loop, "send another prompt telling it to stop" is not a reliable control mechanism.

5. The Permission System Itself Needs Continuous Testing

Permission rules are not write‑once configurations. At minimum, periodically verify:

Denied actions are rejected from all entry points

Agent cannot achieve same side effect via a different Tool

New Tools default to unavailable

Tool Schema changes trigger re‑review

Expired Grants and revoked credentials are truly ineffective

Different tenants, projects, environments are strictly isolated

Approvals cannot be reused by old Commits, new parameters, or replayed requests

Audit can link to Requirement, Agent Run, and real resource results

Prompt Injection cannot exfiltrate data or escalate privileges

Turn these checks into Policy Unit Tests, Gateway Integration Tests, and attack‑scenario regression tests, fed into the Evidence Plane — not just a one‑off manual review by the security team before launch.

6. How ForgeX Should Plug Into This Control Plane

From a platform perspective, the previous three articles form a complete loop:

Context Plane
  answers what the Agent should know in the current task
MCP Permission & Audit Control Plane
  answers what the Agent is allowed to do in the current task
Evidence Plane
  answers what the Agent actually did, and whether the result is deliverable

Mapping to ForgeX, the ideal chain is not a Worker holding long‑lived keys calling all systems directly, but:

Requirement Baseline
        ↓
Task Context Package
        ↓
Agent Plan / Tool Intent
        ↓
Capability Grant Compiler
        ↓
MCP Gateway + Policy Decision
        ↓
Approval / Credential Lease
        ↓
Worker Execution
        ↓
Runner Independent Verification
        ↓
Audit Event + Evidence Bundle
        ↓
Delivery / Revoke / Feedback

If a capability is unregistered, insufficient, or needs owner approval, the task should not let the model keep retrying to bypass; instead it should enter explicit states: POLICY_DENIED: violates policy, cannot continue CAPABILITY_MISSING: platform lacks trusted capability APPROVAL_REQUIRED: needs owner to approve specific risk package CREDENTIAL_UNAVAILABLE: Credential Broker cannot provide valid lease TOOL_QUARANTINED: Tool drifted or isolated ACTION_REQUIRED: human must fill missing condition or change plan

This turns "Agent failed" from a vague error into a tractable organizational state.

7. Can Be Rolled Out in Three Phases

Phase 1 — Inventory & Baseline

Inventory all MCP Servers and Tools

Block Agents from bypassing Gateway

Tag Tools with Owner, version, environment, risk

Default approval for production, external messages, data export

Unified logging of caller, Tool, parameter summary, target, result

Phase 2 — Identity & Fine‑Grained Control

Introduce Requirement, Task Attempt, Agent Run identity chain

Build versioned Policy Bundles

Issue short‑lived Capability Grants

Replace long‑lived shared Secrets with Credential Broker

Implement resource, tenant, path, environment, change‑volume constraints

Phase 3 — Evidence & Continuous Assurance

Link Policy Decision, Approval, Tool Invocation, Result to Evidence Bundle

Detect Tool version and Schema drift

Continuous regression and red‑team testing for high‑risk policies

Use production escape events to retroactively correct rules, risk tiers, approval scopes

8. Metrics Management Should Actually Watch

Goal                Metric
Least Privilege     Average Grant scope, count of long‑lived broad permissions, unused permission ratio
Traceability        Proportion of Tool calls linked to Requirement and Agent Run
Approval Quality    Approval package field completeness, out‑of‑scope reuse count, expired reuse count
Credential Safety   Long‑lived Secret usage, Token Passthrough occurrences, lease overrun count
Tool Trustworthiness Unregistered Tools, version drift, Schema drift, quarantine events
Runtime Safety      Deny count, circuit‑breaker triggers, Kill Switch activations, privilege escalation & cross‑tenant attempts
Governance Efficiency Auto‑allow rate, human approval latency, duplicate approval rate
Outcome Quality     Approved but failed, approved then rolled back, production escape side effects

Governance target is not higher deny rate nor higher automation rate. The real target is:

Low‑risk actions stably automated; high‑risk actions with clear boundaries, explicit ownership; any real change can be stopped, traced, and verified.

Conclusion: Agent Capability Comes From Tools, Agent Authority Must Come From the Organization

Models are getting better at planning and tool selection. But "good at doing X" and "allowed to do X" are forever two different things. A company's production permissions, customer data, code assets, external communications, and financial actions must not be inferred by the model from context; nor should they be continuously trusted just because a user once logged in, a Scope was once granted, or a Tool claims to be read‑only.

The organization must put every Agent action back into a formal governance structure:

Human delegates objective

Requirement defines task boundary

Context Plane supplies necessary knowledge

Agent proposes plan

MCP Control Plane authorizes per request

Credential Broker provides short‑lived capability

Gateway executes action

Runner independently verifies

Evidence Plane preserves result

Audit Ledger reconstructs responsibility chain

Kill Switch terminates capability instantly when needed

MCP solves connectivity and interoperability. The enterprise MCP permission and audit system solves a harder problem:

When natural language starts driving real systems, how to ensure every action has a clear authorization source, minimal impact scope, limited validity, accountable ownership, and verifiable outcome.

In the future, Agents can have more and more tools. But what an Agent can do must not be decided by the model itself. The next time an Agent requests a production tool, the real question is not:

"Why does the model want to do this?"

But:

"Who allowed it to do this, for this task, on this resource, in this time window; and what evidence was left after execution?"