Protocols & Rails — MCP Safety
Tool calls that stay authorised under change.
No Stamp → No Ship for MCP tool calls.
MCP connects models to external tools. That makes tool use a security boundary, not a product feature. Good Proof turns high-impact tool execution into a verifiable, scope-bound, expiry-aware, revocable gate that counterparties can check by link.
- Gate tool calls by Status Link: not VALID → no execute
- Counterparties verify by link: scope • expiry • signer • status
- Evidence Pack (IDA format): time-stamped snapshot you can file
Fail-closed•Append-only•Scope-bounded
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why MCP safety buyers are moving now
Tool-use autonomy, third-party connectors, and enterprise procurement scrutiny are converging.
Tool autonomy outpacing approval workflows
MCP enables models to take irreversible actions — payments, access grants, production writes. Approval registers don't gate tool calls at execution time.
Connector proliferation widens trust boundary
Every new MCP server or connector adds a trust boundary. Existing authorization workflows don't cover scope expansion at call time.
Server/tool/scope drift invalidates prior approvals
Server version updates, capability expansions, and config changes silently invalidate prior tool-use approvals without triggering review.
Enterprise counterparties demand portable proof
Partners, auditors, and procurement need to verify tool authority by link — not by scheduling a meeting or requesting system access.
Incident response requires immediate stop-rely
If a tool server is compromised or credentials leak, you need revocation to propagate instantly wherever the Status Link is checked.
Legal and audit require decision-time defensibility
"What tool authority existed at execution time?" is unanswerable from logs alone when policy, scope, or vendor has changed since.
Privacy constraints block raw evidence sharing
Counterparties need proof of tool governance, but raw prompts, logs, and credentials can't be shared. Minimal-disclosure verification solves this.
Manual reconstruction drains engineering and GRC
Rebuilding what was true at tool-call time from scattered logs, configs, and tickets consumes security and GRC capacity that should be spent on new risk.
Good Proof provides scope-limited verification evidence and stop-rely semantics. It is not a certification.
What a Stamp proves (and what it doesn't)
Proves (within lane scope)
- Action class + outcome marker
- Execution timestamp
- Signer / authority reference
- Scope boundary + expiry + evidence window
- Validity state (VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED)
- Policy / version identifiers
- Evidence window for disputes / audit
Does not prove
- Underlying data correctness
- Tool output quality / accuracy
- Model or policy correctness
- Raw prompts / logs / PII by default
- Certification or regulatory compliance
In disputes: Status Link = reliance state now. IDA Evidence Pack = fileable decision-time snapshot.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why this lane exists
This is an authority-and-timing problem, not only an observability problem.
MCP expands the attack surface because it enables models to take actions, not just generate text. The critical question is not "did the tool call happen" but:
Was execution permitted then, under what scope/version, and should reliance continue now?
Logs are not enough when counterparties cannot verify them. Good Proof converts meeting-checkable process trust into a contract-referenceable, machine-checkable gate.
Status Link tells what is true now. IDA Evidence Pack records what was true then.
MCP capability surface (before execution)
What gets stamped before any tool call runs.
MCP server identity + version
Declared tool families / capability scope
Allowed action classes per lane
Connector configuration boundary (tenant / workspace / project)
Delegation object / authority scope / signer policy
Evidence window + expiry
Material surface change
→ NEEDS_REFRESH
Compromise / integrity failure
→ WITHDRAWN
Unreachable verifier
→ NOT_VERIFIED → block / escalate
What gets stamped (action classes)
High-impact tool execution classes — define per programme.
Data export & external shares
- File export / external share creation
- Sensitive record read/copy to external system
- Bulk data extraction via tool call
Payments & financial instructions
- Payment initiation / approval
- Invoice creation or modification
- Financial threshold override
Access & role changes
- Role/access grant or revocation
- OAuth scope expansion
- API key policy changes
Production writes & ops
- Production database writes
- Infrastructure change operations
- Deployment / rollback triggers
Incident & liability decisions
- Incident closure decisions
- High-liability exception approvals
- Break-glass emergency actions
Outbound comms & tickets
- Sending email / posting messages
- Creating/closing support tickets
- External messaging via tool call
If a tool call can't be safely reversed, it must be verifiable and revocable before it runs.
Integration in 3 touchpoints
1
Issue
At high-impact tool call (file export, payment, access grant) → require a Stamp.
2
Communicate
Include Status Link in outbound messages (partner API, ticket, audit trail).
3
Rely
At execute → verify Status Link (fail-closed). Not VALID → block or escalate.
High-impact gating only. Everything else runs normally.
Live status + fail-closed enforcement
VALID
Proceed within scope.
NEEDS REFRESH
Re-verify before rely.
WITHDRAWN
Stop-rely immediately.
NOT VERIFIED
Fail-closed response.
If it's not VALID, the action does not execute.
Fail-closed: unreachable verification returns NOT_VERIFIED.
Block or escalate, never assume validity.
VALID means valid within scope, not guaranteed correctness.
When status changes — and what it means
Status triggers define when a Status Link moves to NEEDS_REFRESH or WITHDRAWN.
NEEDS_REFRESH
When any of these occur, re-verify before you rely.
MCP server version change
Tool list / capability scope change (new tool added or removed)
Connector boundary change (workspace/tenant/project)
Policy / approval threshold change
Auth scope expansion (OAuth scopes broadened)
SDK / adapter behavior-changing update
Signer / key policy changes
Evidence-window expiry
New high-risk lane added (e.g., payments now permitted)
Monitoring indicates drift from expected tool-usage patterns (programme-scoped)
NEEDS_REFRESH means re-verify before rely, not defer.
WITHDRAWN
Integrity compromised. Stop relying immediately.
Suspected MCP server compromise
Token leakage / credential misuse affecting tools
Tool server misconfiguration enabling out-of-scope actions
Confirmed unauthorized connector scope expansion
Critical vulnerability disclosed affecting this MCP server version
Incident command declares tool boundary untrustworthy
Unauthorized policy edits detected
Verified malicious tool-call pattern attributable to this surface
WITHDRAWN propagates wherever Status Link is checked.
How it works (simple)
1
Stamp the MCP surface
Approve MCP server version + capability scope for a defined lane. If it changes → NEEDS_REFRESH.
2
Gate high-impact tool calls
Before executing, systems check the Status Link. No Stamp / NOT_VERIFIED / NEEDS_REFRESH / WITHDRAWN → block or escalate.
3
Revoke fast when risk changes
If compromise is suspected, mark WITHDRAWN. Revocation propagates by Status Link, not by chasing configurations.
4
Expand lanes after proven reliance
Start with one tool class. Prove it in 30 days. Expand when counterparties rely on the Status Link.
Make the gate machine-checkable, not meeting-checkable.
Two artefacts, one standard
Status Link (authoritative now)
A counterparty-verifiable link that returns current validity within scope.
- Returns: status, scope, expiry, verified_at, signer, verify_url
- Fail-closed: unreachable = NOT_VERIFIED
- Built for contracts, runbooks, tickets, and automated gates
IDA Evidence Pack (snapshot then)
View full details →A time-stamped snapshot you can forward, file, and cite.
- Built for committees, audits, disputes, and procurement
- Append-only history; withdrawal ≠ erasure
- Excludes prompts, logs, PII by default
One Stamp produces both. PDFs are great for filing. Status Links keep them current.
What's inside the IDA Evidence Pack
Action summary + lane scope boundary
Decision-time timestamp + evidence window
MCP server identifier + version references
Capability / policy identifiers
Tool boundary ref (allowed action classes)
Verification transcript + timestamps
Redaction matrix (what's excluded by design)
Minimal disclosure by default: prompts, logs, PII excluded. Programme-gated access when required (auditable trail).
View full IDA Evidence Pack details
What auditors, partners, and buyers can verify
(without your systems)
- Current validity state: VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED
- Scope boundaries: capability + allowed action classes + lane
- Expiry + verified_at timestamp
- Signer authority reference (system or Guardian panel when required)
- Canonical verification route + optional signed response (programme-scoped)
- Forwardable IDA pack for filing, disputes, and procurement
- Optional anchoring to Good Proof LIVE Ledger (high-assurance programmes)
Privacy-preserving by default: prompts/logs/PII excluded. Programme-gated access when required (auditable trail).
Global Coverage
Regulatory reality
No hype, no compliance claims — portable proof for tool governance and third-party risk.
EU
DORA operational resilience + third-party scrutiny; AI Act traceability expectations for high-risk tool-use decisions.
UK
Operational resilience accountability + impact tolerances for critical services; AI safety framework direction.
US
Vendor due diligence, third-party risk guidance, and emerging AI governance expectations; proof that travels.
Canada
OSFI third-party risk expectations; defensible records for high-impact automated decisions.
Australia
APRA CPS 230 operational risk requirements; portable proof reduces escalation friction.
Asia
MAS/HKMA/FSA AI governance and safeguarding expectations across leading hubs.
Middle East
DIFC/ADGM digital governance frameworks expanding; portable verification supports cross-border reliance.
Africa
AU digital governance frameworks strengthening; portable verification supports cross-border and multi-agency reliance.
Good Proof doesn't certify compliance. It makes tool authority verifiable, refreshable, and withdrawable by link.
Jurisdictional Configuration
Country overlays can be configured per programme
Scope boundaries, evidence windows, disclosure/redaction requirements, verifier access rules, retention, language support, and appeal/dispute handling flows are configurable per jurisdiction. Examples include UAE, Saudi Arabia, South Africa, Kenya, Nigeria overlays.
Not legal advice. Final legal mapping is owned by programme counsel.
Where MCP safety bites hardest
Sector-specific tool-use risk patterns driving buyer urgency.
Financial services
Payment, settlement, and custody tool calls with irreversibility risk
Healthcare
PA, UM, and eligibility tool actions with duty-of-care exposure
Pharma & Life Sciences
QMS, PV, and batch-release tool calls under inspection scrutiny
Legal / Professional Services
Document drafting, filing, and client-data export with privilege exposure
Public sector
Eligibility, sanctions, and benefit-determination tool actions under FOI/tribunal review
Telecom
SIM-swap, fraud-block, and service-disconnection tool calls with complaint exposure
Retail / Marketplaces
Listing removal, payout hold, and ban/reinstatement tool calls with seller dispute risk
Industrial / IoT
Safety-envelope, zone-entry, and mode-change tool calls with physical consequence risk
AI-Agent Era
AI-agent era controls
Prompts can drift. Tool scopes can expand. Reliance controls must not.
Material change in server/tool/vendor/configNEEDS_REFRESH
Integrity or boundary breachWITHDRAWN
Timeout/unreachable verification routeNOT_VERIFIED (fail-closed)
Exception lane requiring human finalityGuardian path (optional)
Good Proof does not decide outcomes; it controls whether high-impact actions are safe to rely on.
Who buys MCP Safety
Commercial buyers and external verifiers with tool-governance accountability.
Security / CISO
Pain: MCP turns tool use into an uncontrolled action plane with no execution-time gate.
Outcome: Verifiable gate + instant revocation at tool boundary; portable proof for audit and procurement.
Book an MCP Safety SprintAI Platform / Product Engineering
Pain: Can't ship tool-using features into regulated or enterprise buyers without verifiable controls.
Outcome: "No Stamp → No Ship" turns autonomy into a contractable, machine-checkable control.
Book an MCP Safety SprintPlatform / SRE
Pain: MCP server trust boundaries are assumed, not enforced at call time; drift is invisible.
Outcome: Execute-time gate check: status not VALID → block or escalate. Drift triggers NEEDS_REFRESH.
Book an MCP Safety SprintProcurement / Vendor Risk
Pain: Tool safety assurances don't travel beyond your perimeter; partners can't verify independently.
Outcome: Status Link + IDA pack are forwardable proof artefacts for procurement and partner review.
Book an MCP Safety SprintLegal / Compliance / Audit
Pain: No defensible record of what tool authority existed at execution time when disputes arise.
Outcome: Evidence Pack snapshots with append-only history, redaction matrix, and decision-time timestamp.
Book an MCP Safety SprintGRC / Operational Resilience
Pain: Third-party tool dependencies don't have verifiable risk controls or stop-rely semantics.
Outcome: Scope-bounded verification with withdrawal propagation for incident response and resilience testing.
Book an MCP Safety SprintIncident Response / SOC
Pain: Compromise response requires immediate stop-rely across all downstream reliance points.
Outcome: WITHDRAWN propagates stop-rely signal wherever Status Link is checked — instantly.
Book an MCP Safety SprintExternal verifiers (buyers, auditors, insurers, partners)
Pain: Need to validate tool governance without portal access or system integration.
Outcome: Verify by link; cite IDA snapshot for procurement, compliance, and partner assurance.
Book an MCP Safety SprintWhere budget comes from
Usually funded from existing security, risk, and governance lines — not new category spend.
AI security controls budget
Trigger: MCP adoption expanding tool-use attack surface
Why now: Gate + revocation at tool boundary; no rip-and-replace of existing infrastructure.
Third-party / tool governance budget
Trigger: Connector scope expansion, vendor SDK changes, or multi-tenant risk
Why now: Scope-bounded Stamps with refresh triggers tied to material changes.
Operational resilience budget
Trigger: Third-party risk requirements for tool/connector governance
Why now: Portable verification with withdrawal propagation for incident response.
Legal / audit defensibility budget
Trigger: Audit finding, incident review, or procurement challenge
Why now: Evidence Pack snapshots with append-only history for filing and disputes.
Procurement assurance budget
Trigger: Enterprise deal requiring portable proof of tool governance
Why now: Contract-ready clause template + Schedule A with machine-state definitions.
Incident response / blast-radius budget
Trigger: Compromise response, token leakage, or unauthorized scope expansion
Why now: WITHDRAWN status propagates stop-rely signal wherever checked — instantly.
Start with one high-impact tool class and prove gate + revocation friction reduction before expansion.
24-Month Horizon
Future pressure radar
Conservative assessment of where buyer scrutiny and contractual requirements are heading.
Greater agentic tool autonomy
Models will execute longer chains of tool calls with less human oversight, making pre-execution verification essential.
Heavier connector concentration risk
Fewer, larger MCP server providers increase systemic exposure; buyers will demand verifiable boundary controls.
Stricter external verification requirements
Enterprise procurement and insurance will increasingly require machine-checkable proof of tool governance, not just attestation.
Tighter change-control expectations
Regulators and buyers will expect material changes in tool scope or server version to trigger explicit re-verification.
Faster revocation expectations in contracts
Contractual SLAs for stop-rely propagation will tighten; manual processes won't meet response windows.
More cross-party portability demands
Multi-vendor, multi-cloud, and cross-border deployments will require verification evidence that travels without portal access.
Procurement Ready
Procurement-ready clause
Template language for your legal team.
"For [High-Impact Tool Calls], Supplier shall issue a Good Proof Stamp prior to execution. Buyer may verify status via the Status Link. Stamps returning NOT_VERIFIED, NEEDS_REFRESH, or WITHDRAWN shall block or escalate per programme runbooks."
Schedule A — MCP Safety Verification Requirements
Definitions + operating rules procurement teams can copy/paste.
1. Definitions
"High-Impact Tool Call" means any tool execution class defined in the programme scope that cannot be safely reversed.
"Status Link" means the canonical URL returning current verification status.
"Evidence Window" means the time period during which supporting materials are retained for review.
"IDA Evidence Pack" means time-stamped snapshot for filing and disputes (IDA format).
"Scope Boundary" means the defined limits of what a Stamp covers (decision class, expiry, programme).
2. Required States
Before execution of any High-Impact Tool Call, Supplier shall verify that the Status Link returns VALID.
If the Status Link returns NEEDS_REFRESH, WITHDRAWN, or NOT_VERIFIED, Supplier shall block execution or escalate per programme rules.
Fail-closed: timeout/unreachable ⇒ NOT_VERIFIED.
3. Withdrawal / Stop-Rely Semantics
- WITHDRAWN is returned wherever the Status Link is checked.
- No execution may proceed on WITHDRAWN.
- Optional: programme hooks/notifications for stop-rely distribution.
4. Anti-Spoof Controls
- verify_url host MUST exactly match official verifier domain.
- HTTPS/TLS required. No insecure overrides.
- Redirects forbidden. Domain mismatch ⇒ NOT_VERIFIED.
5. SLA Placeholders
Verification latency SLA: [e.g., p95 < 500ms]
Availability SLA: [e.g., 99.9% uptime]
Revocation propagation window: [e.g., < 60 seconds]
6. Retention + Privacy / Redaction Defaults
- Evidence Pack retains decision-time snapshot for programme-defined retention window.
- Prompts, logs, PII excluded by default; programme-gated access when required.
- Redaction matrix configurable per jurisdiction and programme.
7. Emergency Override Governance
- Programme-defined emergency override lane for continuity-critical tool calls.
- Override requires post-action review + stamped reconciliation.
- Append-only override trail; override ≠ control bypass.
Not legal advice. Template language for your legal team. Acceptance depends on counterparty/programme requirements.
A Global Human Layer
Our Mind Chill Guardian Story
A global human layer that software can't fake.
When liability lands on a person, the sign-off should too.
Conflict-checked · Rotation-based · Audit-traceable · Programme-scoped
When Guardians are used (only when required)
Most tool calls remain automated. Humans step in only where human finality is required: exception approvals, disputes, high-risk overrides, or post-incident outcomes with human liability.
Mind Chill Guardians provide programme-scoped human finality for exception lanes only, with anti-rubber-stamp controls: conflict checks, rotation, sampling audits, and multi-review thresholds for high-risk lanes.
From calming minds to defending outcomes
Mind Chill began in 2017 as immersive art built to reduce anxiety and create calm at scale. Then the same feeds that buried calm and rewarded outrage started training the systems that now make real decisions. We didn't want more rhetoric. We wanted receipts.
The moment it clicked
A message arrived: someone's child felt safer because of what they experienced. Around the same time, lived experience inside our own community made one thing obvious: the nuance that matters in high-impact decisions can't be reliably reduced to a prompt. So we designed a human layer for the edge cases—structured, scope-bound, and auditable.
Guardians are not a "panel." They're a network.
Mind Chill Guardians come from different countries, backgrounds, and lived realities. That diversity is not branding—it's risk reduction. It makes decisions harder to game, easier to challenge, and more credible under scrutiny. Guardians do not "run the system." They review only what the lane requires humans to own.
Receipts over rhetoric
Operational Guardians plug into Good Proof lanes as a controlled finality mechanism: conflict checks, rotation, multi-review where required, and an audit trace tied to a Status Link. Minimal disclosure by default. If a decision is appealed months later, you can show what happened, within scope, without dumping sensitive payloads.
30-day Sprint outcome
What you get in 30 days
One defined tool-use decision class (e.g., "file export" or "payment approval")
MCP capability surface documented
Pre-execution gate integrated (Status Link check)
Refresh triggers and withdrawal conditions configured
Counterparty verification route tested end-to-end
One redacted IDA Evidence Pack specimen generated
Go/no-go expansion recommendation
Due diligence FAQs
Make tool-using AI shippable.
Start with one high-impact tool class. Gate it end-to-end. Expand when counterparties rely on the Status Link.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.