Proposal: Pre-Effectuation Execution-Finality Extension for MCP Tool Calls #3236

sangmdas · 2026-08-13T05:26:56Z

sangmdas
Aug 13, 2026

Proposal: Pre-Effectuation Execution-Finality Extension for MCP Tool Calls

I would like to propose discussion of an optional pre-effectuation execution-finality mechanism for MCP tool calls, particularly for agentic or high-consequence actions.

The core question is:

Should permission to invoke an MCP tool automatically be treated as permission for the resulting action to become externally effective?

For many ordinary tool calls, the present model may be sufficient. However, for actions involving payments, file export, message transmission, infrastructure modification, database writes, credential use, device control, or physical actuation, there may be value in separating computation and tool invocation from authority to create an external consequence.

1. Problem Space

An AI agent may correctly invoke an authorized MCP tool while the resulting action is nevertheless inappropriate because of changed context, revoked permission, destination mismatch, replay, stale authorization, incorrect purpose, excessive scope, or compromised application state.

For example:

an agent may be permitted to use a payment tool but not to authorize every amount or recipient;
a file tool may be available, but a particular document may not be permitted to leave a protected environment;
a messaging tool may be authorized, but the specific recipient, content, or purpose may fall outside the permitted scope;
an infrastructure tool may be callable, but a destructive operation may require stronger validation immediately before execution.

The proposal therefore distinguishes:

permission to request an operation

from

authority for the specific operation to become externally effective.

2. Existing Approaches and Remaining Gap

Existing security mechanisms remain important.

Authentication identifies principals. Authorization determines permitted access. OAuth and similar mechanisms delegate access. User confirmation can approve sensitive requests. Sandboxing constrains applications. Logging and audit systems record activity. Policy engines can evaluate rules.

The proposed mechanism would not replace these approaches.

The narrower question is whether MCP could support an optional standardized mechanism for preserving a proposed operation in a non-effective state until execution-specific conditions have been validated at, or close to, the point where the consequence actually occurs.

This creates a distinction between:

Tool access authorization

and

Specific execution finality authorization.

The latter would be scoped to the particular act rather than functioning as general permission to use the tool.

3. Short Definitions

Candidate Act
A specific proposed operation generated or requested through an MCP workflow that has not yet been permitted to create its intended external consequence.

Non-Effective State
A state in which the Candidate Act may be constructed, inspected, validated, or rejected but cannot yet produce the external effect.

Protected Validation
A validation step that checks execution-relevant conditions such as identity, purpose, destination, scope, freshness, revocation state, limits, or other policy predicates.

Execution Authority
A narrowly scoped authorization associated with the validated Candidate Act. Stronger implementations could bind this authority to the specific act, execution context, security state, destination, freshness value, and consequence boundary so that simple possession or replay is insufficient.

Finality Sink
The consequence boundary responsible for allowing the operation to become externally effective only after the required execution authority has been successfully verified.

The Finality Sink is a logical role rather than necessarily a single physical component.

Examples could include a payment commit boundary, network transmission boundary, file-release boundary, database commit point, device actuator, or another point where an operation becomes externally consequential.

4. Proposed Flow

Conceptually:

MCP Tool Call

↓

Candidate Act

↓

Non-Effective State

↓

Protected Validation

↓

Scoped Execution Authority

↓

Finality Sink Verification

↓

External Effect

If validation fails:

Failure / Timeout / Replay / Revocation / Ambiguity

↓

Default Denial

↓

No External Effect

The important property is that validation occurs before effectuation, rather than relying only on detection, logging, or remediation after the consequence has already occurred.

5. Example

Consider an MCP-connected payment tool.

The agent requests:

send_payment(recipient, amount)

Instead of immediately committing the payment, the system first creates a Candidate Act containing the load-bearing execution attributes.

The payment remains non-effective while the relevant conditions are checked, for example:

authorized agent/application identity;
permitted recipient;
permitted amount;
permitted purpose;
transaction freshness;
current revocation state;
applicable limits;
current security epoch or execution context.

Only after successful validation would scoped execution authority be made available.

The payment consequence boundary would then verify that authority before committing the transaction.

A copied, stale, mismatched, revoked, replayed, or improperly scoped authorization would not be sufficient to cause the payment to become effective.

The same pattern could potentially apply to:

sending messages;
exporting files;
publishing data;
changing cloud infrastructure;
database writes;
API-triggered purchases;
credential use;
robotics or device control;
other high-consequence MCP tools.

6. Why This May Be Useful for Agentic MCP Workflows

Agentic systems can chain multiple tools and make decisions at machine speed.

As tool autonomy increases, the point at which an AI system decides what it wants to do may become increasingly separated from the point at which that decision creates a real-world consequence.

A standardized execution-finality mechanism could provide:

separation of computation from final execution authority;
fail-closed handling of uncertain or invalid execution state;
stronger resistance to stale or replayed authorization;
act-specific rather than broadly reusable authority;
clearer enforcement at consequence boundaries;
more precise auditability of what was actually authorized;
an additional control for high-consequence autonomous workflows;
compatibility with existing authentication and authorization mechanisms rather than replacement of them.

7. Backward Compatibility

I am proposing this as an optional extension, not as a requirement for every MCP tool call.

Ordinary tools could continue operating normally.

Tools or hosts dealing with high-consequence operations could advertise or negotiate support for execution-finality semantics where appropriate.

This could allow incremental adoption without changing the basic MCP interaction model for existing implementations.

8. Questions for the MCP Community

I would appreciate feedback from MCP security, authorization, protocol, and SDK contributors on the following:

Does the distinction between tool-call authorization and authorization for a specific act to become externally effective represent a meaningful problem for MCP?
Should this type of mechanism belong at the MCP protocol/extension layer, or should it remain entirely an implementation concern for hosts and tools?
Would it be useful for MCP to standardize a representation for a Candidate Act and scoped execution authority while leaving the actual validation technology implementation-specific?
Should verification occur primarily at the MCP host, MCP server, tool implementation, or the actual consequence boundary?
Are there existing MCP proposals, authorization efforts, security working groups, or SDK mechanisms that already address this problem?
If the concept is considered useful, what would be the appropriate next step for a minimal reference implementation and potential SEP ( STANDARD ESSENTIAL PATENT ) ?

The intent of this discussion is to understand whether the problem space and architectural boundary are useful to MCP before proposing detailed protocol changes.

sangmdas · 2026-08-23T15:45:42Z

sangmdas Aug 23, 2026
Author

Thanks — I think this is an important distinction, and I largely agree with the concern.

The architecture I am describing is not intended to replace Cedar, OPA, OAuth, MCP authorization, or other policy-decision mechanisms. Those systems can determine whether an actor is permitted to request an operation. The additional problem is what happens after that decision but before an externally consequential action actually occurs.

My proposed boundary is therefore:

policy decision → bounded authorization state → non-effective candidate act → pre-effectuation verification → effect

A permit, policy result, token, or model-side decision is not treated as sufficient merely because it exists. The communication-bearing resource remains non-effective until the enforcement point verifies that the authorization is valid for the specific business/query, purpose, channel, effect, freshness, quota, revocation state, and other required context.

For an AI agent, this means that access to a calling, messaging, booking, or other tool does not itself equal authority to produce every consequence available through that tool. For example, an agent may be authorized to ask a business for availability but not thereby gain authority to expose permanent contact details, create a persistent messaging thread, authorize later callbacks, or repurpose the interaction.

I would therefore describe Cedar/OPA-style systems as possible upstream PDPs rather than competitors. The final enforcement mechanism can consume their decisions as inputs, while independently determining whether the particular consequence may cross the pre-effectuation boundary.

There is also an important difference from a conventional bearer permit: the design does not require the agent itself to possess a reusable signing key or transferable authority. Authorization can instead be scoped, bound to the intended effect and enforcement point, revocable, quota-limited, replay-resistant, and verified immediately before effectuation.

So I agree with the central proposition: a policy decision that cannot constrain the actual effectuation point remains advisory. The purpose of this architecture is to close precisely that last gap between “may act” and “the external effect is actually allowed to happen.”

And I would not characterize this as an AGI-safety proof. It is a narrower systems-security and execution-governance mechanism for controlling externally effective actions.

yaredmengistu04-arch · 2026-08-29T16:51:31Z

yaredmengistu04-arch
Aug 29, 2026

This is exactly the distinction we're testing.
Permission to invoke a tool should not automatically equal authority for every external consequence that invocation could create.
We're prototyping APC as a pre-execution authorization layer where existing IAM/policy systems can approve an operation, but the final side-effect boundary independently verifies that the concrete action still matches the authorized principal, resource and constraints.
Example:
An agent may have permission to call refund(), but that shouldn't automatically authorize:
refund(Customer B, $30,000)
when the approved authority was:
refund(Customer A, <= $300).
Would you evaluate a lightweight implementation of that execution-boundary layer if it integrated with existing authorization infrastructure instead of replacing it?

0 replies

sangmdas · 2026-08-29T16:54:15Z

sangmdas
Aug 29, 2026
Author

Yes — that is exactly the architectural boundary I am interested in. I would evaluate a lightweight implementation, particularly if it sits *after existing IAM/policy authorization rather than replacing it*. The key question for me would be whether the final side-effect boundary independently verifies the *concrete act being effectuated* — principal, resource, amount/parameters, destination, purpose/constraints, freshness/revocation state, etc. — and fails closed if the act no longer matches the authority that was originally approved. Your refund example captures the distinction well: permission to call refund() ≠ authority to effectuate every possible refund. My own work approaches this as an *execution-finality problem*: computation or API permission can produce a Candidate Act, but the externally effective consequence should occur only after a final boundary verifies act-scoped authorization. So yes, I would be interested in looking at the APC prototype, especially the exact object passed to the execution boundary and how you prevent replay, parameter substitution, or bypass through an alternate effectuation path.

…

On Sat, 29 Aug 2026 at 10:21 PM, Yared Mengistu ***@***.***> wrote: This is exactly the distinction we're testing. Permission to invoke a tool should not automatically equal authority for every external consequence that invocation could create. We're prototyping APC as a pre-execution authorization layer where existing IAM/policy systems can approve an operation, but the final side-effect boundary independently verifies that the concrete action still matches the authorized principal, resource and constraints. Example: An agent may have permission to call refund(), but that shouldn't automatically authorize: refund(Customer B, $30,000) when the approved authority was: refund(Customer A, <= $300). Would you evaluate a lightweight implementation of that execution-boundary layer if it integrated with existing authorization infrastructure instead of replacing it? — Reply to this email directly, view it on GitHub <#3236?email_source=notifications&email_token=BVI5P4RFSSACPXENOXQUQJT5MMC2RA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYDIMJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18200418>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVI5P4QP2OC4BFOHPWIC6O35MMC2RAVCNFSNUABIKJSXA33TNF2G64TZHM4DMMRVG4YDKMRTHNCGS43DOVZXG2LPNY5TCMBWGA2DAOBVUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BVI5P4TGL5NDNLIHFM6TO3D5MMC2RA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYDIMJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BVI5P4XS6MDVO2TUB6G2XRT5MMC2RA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYDIMJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: <modelcontextprotocol/modelcontextprotocol/repo-discussions/3236/comments/18200418 @github.com>

1 reply

yaredmengistu04-arch Aug 29, 2026

This is exactly the boundary we're narrowing APC toward.
We're not trying to replace IAM or policy engines. The prototype is focused on the object between the policy decision and the irreversible side effect: an act-scoped execution authority bound to the concrete operation, parameters/resource, constraints, freshness and single-use state.
The three failure modes we're explicitly testing are exactly the ones you mentioned:
replay after a valid authorization,
parameter substitution between authorization and execution,
bypass through an alternate effectuation path.
The key design requirement is that the final side-effect boundary independently verifies the concrete act rather than trusting that permission to invoke refund() means authority for every possible refund.
I'm building the lightweight prototype now. Once it's runnable, I'd genuinely value your review of the exact execution-boundary object and the adversarial tests.

sangmdas · 2026-08-29T18:19:24Z

sangmdas
Aug 29, 2026
Author

Yes — that is now very close to the boundary I had in mind. The three adversarial tests you listed are particularly important: replay, parameter substitution, and alternate-path effectuation. If the final side-effect boundary independently reconstructs or verifies the concrete operation rather than merely trusting an upstream “allow” decision, that is a materially stronger architecture than ordinary tool-call authorization. I would definitely be interested in reviewing the runnable prototype. When you reach that stage, the parts I would look at most closely are: 1. exactly what attributes are cryptographically or otherwise inseparably bound into the act-scoped execution authority; 2. whether the execution boundary validates the actual effect being released rather than only the original request; 3. how single-use / freshness state is enforced under concurrency and retries; 4. whether an equivalent side effect can escape through another API, tool, IPC, service, or execution path; and 5. what happens if authorization state changes after approval but before effectuation. That last boundary — between an authorized computation and the first externally effective consequence — is the area I have been calling execution finality. Happy to review the execution-boundary object and adversarial test cases when the prototype is available.

…

On Sat, 29 Aug 2026 at 10:33 PM, Yared Mengistu ***@***.***> wrote: This is exactly the boundary we're narrowing APC toward. We're not trying to replace IAM or policy engines. The prototype is focused on the object between the policy decision and the irreversible side effect: an act-scoped execution authority bound to the concrete operation, parameters/resource, constraints, freshness and single-use state. The three failure modes we're explicitly testing are exactly the ones you mentioned: replay after a valid authorization, parameter substitution between authorization and execution, bypass through an alternate effectuation path. The key design requirement is that the final side-effect boundary independently verifies the concrete act rather than trusting that permission to invoke refund() means authority for every possible refund. I'm building the lightweight prototype now. Once it's runnable, I'd genuinely value your review of the exact execution-boundary object and the adversarial tests. — Reply to this email directly, view it on GitHub <#3236?email_source=notifications&email_token=BVI5P4RO7FLYYPDOTTAIIVL5MMEGLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYDIOJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18200498>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVI5P4XBRRAPIQ5LB3WWTVL5MMEGLAVCNFSNUABIKJSXA33TNF2G64TZHM4DMMRVG4YDKMRTHNCGS43DOVZXG2LPNY5TCMBWGA2DAOBVUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BVI5P4WLBJ5EZX23NMMBJXD5MMEGLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYDIOJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BVI5P4WSAWSFVDKFMZX4TST5MMEGLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYDIOJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: <modelcontextprotocol/modelcontextprotocol/repo-discussions/3236/comments/18200498 @github.com>

0 replies

bhooshanvarma · 2026-09-02T16:24:33Z

bhooshanvarma
Sep 2, 2026

This proposal is very close to a boundary we have been testing from the evidence-freshness side.
One useful distinction may be to keep execution authorization and evidence freshness separate.
A tool call can still be permitted and structurally valid while the external evidence that justified that specific action has changed after the agent reasoned.
FreshCtx 0.9.0 now implements this as an optional MCP Guard at the native tools/call boundary in the MCP Python SDK v2. Each protected tool declares the FreshCtx dependencies its decision relied on, and those dependencies are revalidated immediately before the handler executes.
The outcomes are deliberately narrow:
CURRENT → handler proceeds
STALE_SOURCE / STALE_REASONING → handler is blocked
UNVERIFIABLE → handler is blocked because freshness cannot be established
Different protected tools can have independent dependency sets, and unprotected tools pass through normally.
I would not treat this as a substitute for the execution-finality / authorization mechanism proposed here. It seems complementary:
“Is this specific act authorized to become effective?”
versus
“Is the evidence that justified this specific act still current?”
We have a bounded MCP reproduction here:
https://github.com/orgs/modelcontextprotocol/discussions/852
FreshCtx 0.9.0:
https://github.com/Hyperwise-LLC/freshctx/releases/tag/v0.9.0
I’d be interested in whether you see evidence freshness as one of the predicates inside your proposed Protected Validation step, or whether you would keep it as an adjacent application-level control before execution finality.

0 replies

sangmdas · 2026-09-02T16:52:35Z

sangmdas
Sep 2, 2026
Author

Thank you — I see the two controls as complementary, and I would keep their semantics separate. In the architecture I am proposing, evidence freshness can become one of the predicates evaluated during Protected Validation when that evidence is load-bearing for the specific Candidate Act. For example, if a transfer was justified by a particular balance, entitlement, approval state, inventory state, or other external fact, Protected Validation could require a current freshness result before finality authority is produced. I would not, however, make the execution-finality layer itself responsible for determining freshness. A mechanism such as FreshCtx could remain the specialized freshness/revalidation function and supply the result into Protected Validation. So, roughly: evidence/dependencies → freshness revalidation → Protected Validation/PED → finality authority → Finality Sink → external effect. This preserves the distinction you identified: “Is the evidence that justified this act still current?” and “Is this exact act authorized to become effective?” The important point for execution finality is that, where freshness is declared as a required predicate, a stale or unverifiable result cannot merely generate a warning or audit event — it prevents valid finality authority for that Candidate Act from reaching the controlled effectuation path. I think your tools/call implementation is therefore a particularly interesting upstream integration point rather than a competing mechanism.

…

On Wed, 2 Sep 2026 at 9:54 PM, bhooshanvarma ***@***.***> wrote: This proposal is very close to a boundary we have been testing from the evidence-freshness side. One useful distinction may be to keep execution authorization and evidence freshness separate. A tool call can still be permitted and structurally valid while the external evidence that justified that specific action has changed after the agent reasoned. FreshCtx 0.9.0 now implements this as an optional MCP Guard at the native tools/call boundary in the MCP Python SDK v2. Each protected tool declares the FreshCtx dependencies its decision relied on, and those dependencies are revalidated immediately before the handler executes. The outcomes are deliberately narrow: CURRENT → handler proceeds STALE_SOURCE / STALE_REASONING → handler is blocked UNVERIFIABLE → handler is blocked because freshness cannot be established Different protected tools can have independent dependency sets, and unprotected tools pass through normally. I would not treat this as a substitute for the execution-finality / authorization mechanism proposed here. It seems complementary: “Is this specific act authorized to become effective?” versus “Is the evidence that justified this specific act still current?” We have a bounded MCP reproduction here: https://github.com/orgs/modelcontextprotocol/discussions/852 FreshCtx 0.9.0: https://github.com/Hyperwise-LLC/freshctx/releases/tag/v0.9.0 I’d be interested in whether you see evidence freshness as one of the predicates inside your proposed Protected Validation step, or whether you would keep it as an adjacent application-level control before execution finality. — Reply to this email directly, view it on GitHub <#3236?email_source=notifications&email_token=BVI5P4SKMVAY6L4R7WQGKFL5NBCVLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTCMZWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18253136>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVI5P4VL2L2QEXJ2EETK7VL5NBCVLAVCNFSNUABIKJSXA33TNF2G64TZHM4DMMRVG4YDKMRTHNCGS43DOVZXG2LPNY5TCMBWGA2DAOBVUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BVI5P4SZNGVA4QXKFMATH335NBCVLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTCMZWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BVI5P4STMYFFPQRAUN5OVWD5NBCVLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTCMZWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: <modelcontextprotocol/modelcontextprotocol/repo-discussions/3236/comments/18253136 @github.com>

1 reply

bhooshanvarma Sep 17, 2026

Hi Sangam — circling back on the bounded example we discussed. I’d still like to turn the composition into one small public test: an entitlement is read at version A, the authoritative state changes before execution, FreshCtx revalidates the dependency, Protected Validation either produces or refuses finality authority, and an independent observer records the resulting effect.

If you’re still open to reviewing it, I can prepare the mock fixture and a short expected-results table. I’ll keep it to one scenario and the interface between the two controls, without proposing any change to the protocol scope.

bhooshanvarma · 2026-09-02T18:57:26Z

bhooshanvarma
Sep 2, 2026

Thank you, Sangam. This separation makes sense to me. FreshCtx should remain responsible for the narrow freshness question, while Protected Validation decides whether the complete Candidate Act has satisfied every predicate required for finality. The integration boundary you describe is especially useful: FreshCtx can supply a structured CURRENT, STALE or UNVERIFIABLE result, and Protected Validation can treat that result as mandatory where the declared evidence is load-bearing for the act. That preserves independent semantics while ensuring that stale evidence cannot reach the effectuation path as a validly authorized action. I would be interested in defining one small, bounded example around this chain: evidence dependency → FreshCtx revalidation → Protected Validation decision → finality authority or refusal → observed external effect A simulated transfer or entitlement change would probably make the separation easiest to inspect. We could document the interface and expected evidence without suggesting that either control replaces the other.

…

On Wed, Sep 2, 2026 at 10:52 AM Sangam Das ***@***.***> wrote: Thank you — I see the two controls as complementary, and I would keep their semantics separate. In the architecture I am proposing, evidence freshness can become one of the predicates evaluated during Protected Validation when that evidence is load-bearing for the specific Candidate Act. For example, if a transfer was justified by a particular balance, entitlement, approval state, inventory state, or other external fact, Protected Validation could require a current freshness result before finality authority is produced. I would not, however, make the execution-finality layer itself responsible for determining freshness. A mechanism such as FreshCtx could remain the specialized freshness/revalidation function and supply the result into Protected Validation. So, roughly: evidence/dependencies → freshness revalidation → Protected Validation/PED → finality authority → Finality Sink → external effect. This preserves the distinction you identified: “Is the evidence that justified this act still current?” and “Is this exact act authorized to become effective?” The important point for execution finality is that, where freshness is declared as a required predicate, a stale or unverifiable result cannot merely generate a warning or audit event — it prevents valid finality authority for that Candidate Act from reaching the controlled effectuation path. I think your tools/call implementation is therefore a particularly interesting upstream integration point rather than a competing mechanism. On Wed, 2 Sep 2026 at 9:54 PM, bhooshanvarma ***@***.***> wrote: > This proposal is very close to a boundary we have been testing from the > evidence-freshness side. > One useful distinction may be to keep execution authorization and evidence > freshness separate. > A tool call can still be permitted and structurally valid while the > external evidence that justified that specific action has changed after the > agent reasoned. > FreshCtx 0.9.0 now implements this as an optional MCP Guard at the native > tools/call boundary in the MCP Python SDK v2. Each protected tool declares > the FreshCtx dependencies its decision relied on, and those dependencies > are revalidated immediately before the handler executes. > The outcomes are deliberately narrow: > CURRENT → handler proceeds > STALE_SOURCE / STALE_REASONING → handler is blocked > UNVERIFIABLE → handler is blocked because freshness cannot be established > Different protected tools can have independent dependency sets, and > unprotected tools pass through normally. > I would not treat this as a substitute for the execution-finality / > authorization mechanism proposed here. It seems complementary: > “Is this specific act authorized to become effective?” > versus > “Is the evidence that justified this specific act still current?” > We have a bounded MCP reproduction here: > https://github.com/orgs/modelcontextprotocol/discussions/852 > FreshCtx 0.9.0: > https://github.com/Hyperwise-LLC/freshctx/releases/tag/v0.9.0 > I’d be interested in whether you see evidence freshness as one of the > predicates inside your proposed Protected Validation step, or whether you > would keep it as an adjacent application-level control before execution > finality. > > — > Reply to this email directly, view it on GitHub > < #3236?email_source=notifications&email_token=BVI5P4SKMVAY6L4R7WQGKFL5NBCVLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTCMZWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18253136>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/BVI5P4VL2L2QEXJ2EETK7VL5NBCVLAVCNFSNUABIKJSXA33TNF2G64TZHM4DMMRVG4YDKMRTHNCGS43DOVZXG2LPNY5TCMBWGA2DAOBVUF3AE> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > < https://github.com/notifications/mobile/ios/BVI5P4SZNGVA4QXKFMATH335NBCVLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTCMZWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> > and Android > < https://github.com/notifications/mobile/android/BVI5P4STMYFFPQRAUN5OVWD5NBCVLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTCMZWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. > Download it today! > You are receiving this because you authored the thread.Message ID: > <modelcontextprotocol/modelcontextprotocol/repo-discussions/3236/comments/18253136 > @github.com> > — Reply to this email directly, view it on GitHub <#3236?email_source=notifications&email_token=BQ6PLJTJT5BCIVCZWYMVLWD5NBF6TA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTKMZSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18253532>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BQ6PLJWLF7WMDP3UTUFU2BL5NBF6TAVCNFSNUABIKJSXA33TNF2G64TZHM4DMMRVG4YDKMRTHNCGS43DOVZXG2LPNY5TCMBWGA2DAOBVUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BQ6PLJSODXDYKD2T4V3OOKD5NBF6TA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTKMZSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BQ6PLJXRDPCJAWMGPJONSTL5NBF6TA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGUZTKMZSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: <modelcontextprotocol/modelcontextprotocol/repo-discussions/3236/comments/18253532 @github.com>

0 replies

samvallad33 · 2026-09-16T03:47:46Z

samvallad33
Sep 16, 2026

The distinction this proposal draws between invocation permission and effectuation permission is, in my experience building an agent security kernel, the single most important line the protocol could draw, because the failure reports across the ecosystem almost all share one shape, an agent that was authorized to use a tool and then produced an effect nobody would have authorized if it had been asked about directly. Payments and file deletion and infrastructure changes all live behind tool calls that look identical to harmless ones right up to the moment they execute.

I build an open source project called Vestige that implements this boundary as a working system, where tool invocation yields a proposal, the kernel evaluates the effect class and resolved targets, and only a one use permit issued at the effect boundary lets anything become externally real, with signed receipts recording the whole chain. Destructive classes additionally route to human review rather than implicit consent from invocation.

I think the protocol question that still needs answering is what the effect class declaration looks like and who is trusted to set it, since caller settable flags are defeatable, and I would be glad to contribute the schema and the failure modes we hit while building that evaluation layer into this discussion.

1 reply

bhooshanvarma Sep 17, 2026

Sam, the one-use permit and signed-receipt path sounds like a useful system to test against this boundary.

FreshCtx handles a different predicate immediately before execution: whether the external evidence supporting the proposed act is still current. Revera then observes the resulting execution independently. A small comparison could use a mock refund or entitlement change:

construct the candidate act from evidence at version A;
change the authoritative evidence to version B;
evaluate the Vestige permit at the effect boundary;
record the FreshCtx result as CURRENT, STALE, or UNVERIFIABLE;
compare both records with the backend effect observed independently.

That would show whether the permit, freshness result, receipt, and actual effect compose cleanly without treating any one record as proof of the others.

If the effect-boundary implementation or an equivalent test fixture is public, point me to the exact path. I can map the smallest reproducible matrix before suggesting any integration work.

Proposal: Pre-Effectuation Execution-Finality Extension for MCP Tool Calls #3236

Uh oh!