Proposal: Permission Specification for MCP Tool Calls

[stevenkozeniesky02]

Summary

I would like to propose a standard format for expressing, evaluating, and auditing permission rules for MCP tool calls — the AgentsID Permission Specification v1.0.

The full spec is published at agentsid.dev/spec and github.com/stevenkozeniesky02/permission-spec. This post summarizes the motivation, design, and asks for feedback from MCP maintainers.

---

Motivation

MCP gives agents unrestricted access to every tool a server exposes by default. The spec delegates authentication to the transport layer and provides no mechanism for:

• Per-tool authorization (which tools can this agent call?)
• Parameter constraints (what values are acceptable?)
• Delegation (can an agent grant a subset of its permissions to a sub-agent?)
• Audit trails (what did the agent do, when, and under whose authority?)

We recently scanned 100 MCP servers using an open-source scanner (@agentsid/scanner) and published the results in "The State of MCP Server Security 2026".

Key findings:

• 71% of servers scored F on our security framework
• Every vendor-maintained reference implementation scored F (including server-github and server-filesystem)
• We identified 163 hallucination-based vulnerabilities — a novel class where vague tool definitions cause LLMs to over-privilege, misroute, or expand scope beyond developer intent
• The structural preconditions are identical to those in CVE-2025-68143, CVE-2025-68144, and CVE-2025-9611

We filed two issues on this repo:

• #3751 — push_files scope constraints
• #3752 — filesystem path traversal

The root cause in both cases is not buggy code — it is the absence of a standard way to express what an agent is permitted to do.

---

The Proposal

A permission policy is a JSON document attached to an agent. A pure-function evaluation engine decides allow/deny at tool call time. An audit log records every decision with cryptographic integrity.

Permission Rule Format

{
  "version": "1.0",
  "agentId": "agent_abc123",
  "expiresAt": "2026-04-29T00:00:00Z",
  "rules": [
    {
      "tools": ["github.push_files"],
      "action": "allow",
      "conditions": {
        "owner": { "pattern": "^myorg$" },
        "branch": { "enum": ["main", "develop"] }
      },
      "constraints": [
        { "type": "rateLimit", "max": 10, "windowSeconds": 3600 }
      ]
    },
    {
      "tools": ["**"],
      "action": "deny"
    }
  ]
}

Core Principles

Principle	Description
Deny-first	Absent a matching allow rule, all tool calls are denied
Least privilege	Rules grant the minimum necessary access
Composable	Rules combine without conflict via explicit priority
Portable	The spec is a JSON schema, not a platform dependency
Auditable	Every decision is logged with cryptographic integrity

Constraint Types (12 built-in)

Schedule, Rate Limit, Data Classification, Budget, Sequence, Session Limit, Risk Score, IP Allowlist, Chain Depth, Cooldown, Anomaly Detection, Approval Gate — plus x- prefixed extensions.

Delegation Protocol

Agents can delegate a subset of their permissions to sub-agents. Scope can only narrow, never expand. Revoking a delegation cascades to all sub-delegations immediately.

Audit Log

Every evaluation decision produces an append-only audit entry with SHA-256 hash chaining. Any tampering with a historical entry invalidates all subsequent hashes.

---

Relationship to Existing MCP Auth Work

This proposal is a complement to, not a replacement for, the MCP auth spec (OAuth 2.1 / transport-level authentication). The auth spec answers "who is this agent?" This proposal answers "what is this agent allowed to do, with what parameters, under what conditions?"

These are orthogonal problems. You need both.

---

What I Am Asking

1. Feedback on the design — are there MCP-specific constraints or patterns that the spec should account for?
2. Is there appetite for a permission layer in MCP v2? — if so, I would like to contribute this spec as a starting point for a working group discussion
3. Reference implementation — AgentsID provides a production implementation at agentsid.dev. We would be happy to donate the spec itself to the AAIF under CC-BY 4.0 if there is interest in neutral governance

---

Links

• Full spec: agentsid.dev/spec
• Spec repo: github.com/stevenkozeniesky02/permission-spec
• Scanner: npx @agentsid/scanner
• Research paper: The State of MCP Server Security 2026

[jagmarques]

The 71% F-score finding across MCP servers is not surprising but it is useful to have quantified. The structural problem is that MCP defaults to "all tools available to all callers" and the spec provides no opt-in mechanism for restriction.

On the design questions:

1. Policy metadata should live in tools/list responses, not a separate method. An extra round-trip to discover permissions means most lightweight clients will skip it entirely, which defeats the purpose. Inline policy fields that default to unrestricted maintain backward compatibility while giving security-conscious implementations something to enforce.

2. The delegation protocol (scope can only narrow, never expand) is the right constraint. The cascading revocation is important too - without it, a revoked parent delegation leaves orphaned sub-delegations that are still technically valid.

The chain depth constraint type is underrated. Most real exploits in agent systems come from deep delegation chains where no single hop looks dangerous but the cumulative capability is.

[stevenkozeniesky02]

@jagmarques @tysoekong you are both landing on the same point independently and I think you are right. The separate-method approach was my original design because it keeps the policy document self-contained and portable. But the practical argument wins: if discovering permissions requires an extra round-trip, most clients will skip it. And for gateways aggregating dozens of servers, name-matching tools to an external ACL config is exactly the kind of thing that breaks the moment a new server is added dynamically.

The inline approach could work as optional fields on the tool definition in tools/list:

{
  "name": "push_files",
  "description": "Push files to a repository",
  "inputSchema": { ... },
  "permissions": {
    "scopes": ["repo:write"],
    "constraints": [
      { "type": "rateLimit", "max": 10, "windowSeconds": 3600 }
    ]
  }
}

Servers that do not include the permissions field default to unrestricted (backward compatible). Servers that do include it give clients and gateways something to enforce without a second call.

tysoekong's scopes/roles condition type is a good addition. The current spec handles parameter-level constraints but not caller-identity conditions. Adding a standard scopes field gives the agent early feedback that it lacks privilege, which is better than a blind denial after attempting the call.

I'll update the spec to support both modes: inline policy hints on tools/list for lightweight enforcement, and the full policy document for systems that need delegation chains, audit, and cross-server composition. The inline fields would be a subset of the full spec, not a separate schema.

The chain depth point is underrated. The most dangerous delegation chains we've seen in production are ones where each individual hop looks innocuous.

[tysoekong]

The issue we are having is that there is no provision for e.g. "ACLs" on individual tools.

It can be driven by the tool metadata map, however this then becomes implementation-specific, and not portable.

When aggregating many servers on a gateway, right now the only options is to name-match the backend tool to an ACL defined in the gateway config, and apply it per-request. This is not so scalable, if MCP is to implement a whole discovery mechanism whereby tool servers can be discovered and loaded in dynamically, and the developer does not need to change anything at the "gateway", then per-tool scope-definitions are needed in the tools list response.

Under the conditions or constraints, I think it would make sense to also make sense to deliver a standard "role" type matching:

{
  ...
  "conditions": {
    "scopes": { "enum": ["admins", "financial_read"] }  # or "roles"
  }
  ...
}

This would deliver to the agent the idea that the current context does not have the scope to execute this tool. Then the server must enforce this restriction but at least there is an early feedback loop to the user/agent that they need higher privilege.

[stevenkozeniesky02]

@arian-gogani the permissions vs behavioral constraints distinction is the right framing. We have been treating these as one layer but they are two distinct enforcement points.

Permissions: "can this agent call transfer?" — binary gate, evaluated before execution.
Behavioral constraints: "can this agent call transfer with amount=600?" — parameter-level evaluation, also before execution but with richer semantics.

The current spec handles both through the conditions field on permission rules (parameter pattern matching, enum constraints). But your covenant syntax is cleaner for expressing behavioral intent. permit transfer (amount <= 500) reads better than a JSON condition block doing the same thing.

The SHA-256 hash-chained log convergence is interesting. We arrived at the same design independently, which suggests it is the natural solution for tamper-evident agent audit trails.

I'd be interested in how Nobulex handles constraint composition when multiple covenants apply to the same tool call. In our spec, rules are evaluated in priority order with deny-first default. If your behavioral constraints layer sits alongside the permission layer, there needs to be a defined evaluation order between them.

Will check out the playground. If there is an opportunity to make the two systems composable — AgentsID permission rules feeding into Nobulex behavioral enforcement — that could be a strong combined offering for the spec discussion.

[aman210122]

Strong proposal. The per-tool authorization gap is real. I want to raise a related problem that compounds it: what happens to permissions when content flows through derivation chains?
Scenario from healthcare: Agent A processes a HIPAA-regulated clinical note (restricted to clinicians). Agent B processes SOX-regulated financial data (restricted to executives). Agent C combines both outputs into a summary. What permissions should apply to Agent C's output?
If you only enforce permissions at the tool call boundary, Agent C's output has no governance. It was produced by an authorized agent, so the tool call was allowed. But the output contains derived information from both HIPAA and SOX sources. Anyone who can read Agent C's output now has indirect access to both regulated sources.
In our deployments, we found that permissions need to compose under derivation: sensitivity should take the max of all sources, access control should intersect (only roles authorized for ALL sources can read the derivative), and regulatory tags should union (all obligations propagate). This way, Agent C's output automatically inherits the most restrictive governance from its inputs.
This is complementary to your tool-level permission spec. Your proposal controls who can call which tool. The composition problem controls what governance applies to the output after the tool produces it. Both are needed for a complete enterprise solution.
Curious if others are seeing this derivation-chain problem in practice.

[stevenkozeniesky02]

@aman210122 the derivation chain problem is real and it is the gap I have been avoiding because it is genuinely hard.

Your composition rules — max sensitivity, intersect access, union regulatory tags — are the right semantics. We saw a simpler version of this in multi-agent delegation chains: agent A has access to financial data, delegates to agent B with narrowed scope, agent B produces a summary that implicitly contains the restricted data. Our delegation protocol handles scope narrowing on the permission side but does not track what information is embedded in the output.

The healthcare scenario is the sharpest example. HIPAA + SOX derivation means the output inherits the most restrictive governance from all sources. If you only enforce at the tool call boundary, the output is unclassified despite containing classified inputs.

I think this belongs as a governance extension to the permission spec rather than in the core. The core handles pre-execution authorization (can you call this tool with these parameters). Output governance is a post-execution concern that requires tracking data lineage through the agent graph, which is a different problem with different enforcement points.

That said, the spec should define the hooks for it. An audit entry that records input source classifications alongside the tool call result would give a governance layer enough information to apply your composition rules after the fact.

Would like to see the formal definitions and test cases when you put them together. This is the kind of thing that needs concrete examples to get the semantics right.

[arian-gogani]

@AmanSharma2609 the derivation chain problem is real and I keep seeing it come up independently across these discussions — which means it's a real gap, not a theoretical one.

The composition rules you landed on (max sensitivity, intersect access, union regulatory) are the same ones you described in #2493. The fact that you arrived at them through deployment testing rather than theory is the strongest validation.

For the permission spec specifically: tool-level permissions + output governance composition are two different enforcement points that both need to exist. The permission spec handles the first. Your composition rules handle the second. Proof-of-behavior can enforce both and log the evidence for each decision.

The enforcement middleware could evaluate two constraint sets per action:

1. "Is this agent allowed to call this tool?" (permission check)
2. "Given the sources this output derives from, what governance applies?" (composition check)

Both decisions go into the same hash-chained log. Auditor replays both.

This is converging with the work in cxp-protocol — would be worth formalizing the composition rules as part of the governance vocabulary crosswalk happening in agent-governance-vocabulary.

[aman210122]

Good point on the dual constraint set. The pre-execution permission check and post-execution composition check are distinct enforcement points that both need to exist.
Happy to contribute the composition semantics and test cases to the governance vocabulary crosswalk if that effort moves forward.

[stevenkozeniesky02]

@arian-gogani @aman210122 the governance vocabulary crosswalk at aeoess/agent-governance-vocabulary#10 is exactly where the AgentsID permission spec should be mapped. The spec defines 12 constraint types and a delegation protocol — having those terms in a shared vocabulary alongside Nobulex's behavioral constraints and the composition semantics would make all three interoperable.

Please tag me on that issue when you are ready. I can contribute the AgentsID constraint type definitions and the evaluation algorithm semantics. The deny-first evaluation order, priority resolution, and scope narrowing rules are the pieces that need formal definitions if they are going to compose with other governance systems.

This conversation is converging on a layered architecture:

1. Permission layer — who can call what (AgentsID spec)
2. Behavioral constraint layer — how they can call it (Nobulex covenants)
3. Output governance layer — what rules apply to derived data (composition semantics)

All three enforcement points log to a shared audit trail. That is a complete governance stack for agent tool calls.

[aman210122]

This layered framing makes sense. Permission (who can call what), behavioral constraints (how they can call it), and output governance (what rules apply to derived data) are three distinct enforcement points that all need to exist independently but compose together.
I will contribute the composition semantics formal definitions to the vocabulary crosswalk. The core rules are straightforward: under derivation, sensitivity takes max, access control intersects, regulatory tags union. The key design constraint is monotonicity: governance can become more restrictive through the derivation chain but never less restrictive without explicit human override.
Will follow up on aeoess/agent-governance-vocabulary#10.

[aman210122]

Sounds good. Feel free to tag me on the vocabulary repo when you are ready for the composition semantics. I will put together the formal definitions and test cases.

[Ram9199]

The overlap I see with this permission-spec proposal is the verifiable part of authorization: per-tool authorization, parameter constraints, delegation, and audit trails only become dependable if an approval or grant can be checked against the exact tool call being made.

Limitation: a request-binding invariant is narrower than a full MCP permission language. It does not define every policy primitive, OAuth shape, or UI workflow. It is more like a conformance property: the runtime must reject stale, replayed, or widened approvals.

For that piece, would you want it to be something implementations depend on, a library, a spec/conformance test-kit, or something each MCP client/server project implements directly?

[blah-mad]

I'd start with a spec/conformance test-kit rather than one library. The invariant that matters is: an approval or grant has to bind to the exact tool name, input envelope, actor, workspace/user context, expiry, and decision id. If a gateway can replay, widen, or context-swap that call and still pass, the permission layer is mostly theater.

[davidjbrossard]

Hi,

I wonder whether you have considered existing authorization standards for this. It looks like your architecture follows the PEP/PDP model (as defined in NIST ABAC 800-162) which means you could consider going down the path of OpenID AuthZEN. That would let you delegate the definition of permissions to existing Policy Decision Points (PDP). These could be:

• Open Policy Agent (OPA) fueled by Rego. Rego is widespread especially in infrastructure use cases but is a complex language
• AWS Cedar. A new library by AWS
• ALFA, the Abbreviated Language for Authorization, based on the mature XACML standard and widely adopted in the industry. Check https://alfa.guide for info.

That would solve your AuthZ problem and make it repeatable, i.e. use the same mechanisms in MCP but also A2A and other parts of the AI architecture.