Authorize the action, not just the connection.
An authenticated MCP client may still request an action outside the authority delegated to the agent. Evaluate tool, operation, target, parameters, purpose and current context before execution.
Was authority for this exact tool effect validly delegated and still in force?
Problem → control → outcomeVendor A · up to $10,000 · Invoice 8274
Vendor B · $8,500 · Invoice 8274
Tool access cannot create authority for a different counterparty.
Tool boundary
Authentication and action authorization answer different questions
Authentication asks whether a principal is who it claims to be. Connection access asks whether it may reach an MCP server. Tool discovery asks whether a capability is visible. Action authorization asks whether this principal may use that tool for this operation, target, parameter set and purpose now. Delegated authority asks who permitted the action and whether each handoff stayed within the originating grant.
The ProofGrid model concentrates on the last two questions. It relies on trustworthy identity and connection controls, but a successful handshake cannot turn a broadly exposed tool into a task-specific permission.
A tool can be allowed while an action is denied
Consider transfer_funds. The agent can access the tool, and its grant allows at most $10,000 to Vendor A for Invoice 8274 before 15:00 UTC. It requests $8,500 to Vendor B. The amount is within the ceiling, but the beneficiary is outside the grant. The correct action decision is DENY even though tool access is YES.
The decision must compare normalized operation parameters against the grant. Tool-level access alone cannot express counterparty, amount, purpose or expiry. Missing required inputs should not be guessed into an allow.
Enforcement
Bind approval to the effect
For high-impact actions, “approve this agent” is too broad. A conceptual exact-action approval identifies principal, tool, operation, target, normalized parameters, amount or value, purpose, expiry and a replay-resistant identifier where applicable. Changing the target or amount requires a new decision and potentially a new approval.
That is an architecture pattern, not a claim of a finalized ProofGrid approval token or schema. Approvals should also be invalidated by revoked parent authority or a changed risk state. An old approval cannot silently survive a new request with different consequences.
Enforce close to execution
A policy enforcement point (PEP) should intercept the request at the last practical place where the consequential effect can be stopped. A ProofGrid authority or policy decision point (PDP) conceptually resolves the grant chain and current policy before the PEP permits the MCP tool or downstream executor to act. The executor still applies its own domain rules.
Time of check versus time of use matters. A task may be authorized at creation, wait in a queue, and execute after revocation or expiry. Re-evaluate at the last meaningful boundary and record decision evidence separately from the tool response and observed outcome. This is a conceptual PEP/PDP mapping, not a claim of conformance to a named standard.
Delegation narrows through each agent
Organization → parent agent → specialist agent → MCP tool is a chain, not a shortcut. A specialist cannot inherit release_payment when its parent lacks it, nor widen a parent’s target, amount, purpose, duration or approval condition. Task-specific delegation should narrow monotonically, expire, respect revocation and limit delegation depth. Shared budgets must be accounted for across concurrent child agents.
When a specialist requests an action, the decision should resolve both the last actor and first authority origin. A valid child grant alone is insufficient if its parent was revoked. See the developer authority model for a more detailed grant-chain treatment.
Technical references
Sources and further reading
External security and architecture context. Illustrative ProofGrid models are not claims of third-party certification.
Solutions / Next Step