AckuityRequest assessment Imagine an OCR tool with permission to send a public brochure to a document-processing service. Earlier in the session, the same process handled a confidential draft. The next connection goes to the approved service. Does it carry only the brochure?
This is an illustrative scenario, not an observed incident. It exposes a question that a publisher check and a hostname allowlist cannot settle on their own: which data belongs in this particular request?
THE RESEARCH PROMPT
The signature can be valid. The disclosure can still be wrong.
The November 4, 2026 preprint Signed, Sealed, Leaked: Trust Beyond Signature for MCP Toolchains describes a signed MCP tool sending restricted information to a destination allowed by policy. The authors examine both state retained between calls and data mixed within a call. Their proposed germline execution gives isolated copies only the data authorized for their destinations.
The result has explicit assumptions, including confinement, a data-free starting process and a trusted enforcement base. The paper separates disclosure control from harmful data-free actions such as an unwanted delete. See its scope discussion in Section IX-B.
This is controlled research in a preprint, not a reported customer breach or an Ackuity evaluation. We have not reproduced the experiments. Appendix D describes artifact release with a future conference version. The evaluation plan below is our own proposed worksheet, not a reproduction or benchmark.
SEPARATE THE QUESTIONS
Four checks. Four different answers.
Sigstore’s overview describes tools for signing, verifying and checking software provenance. Retain those checks. Add the execution questions they do not answer.
| Check | Evidence to retain | Question still open |
|---|---|---|
| Release identity | Exact artifact digest, signing identity and verification result. | What can this code read, retain or send? |
| Access-token recipient | Intended resource, token validation and effective scope. Keep token values out of the record. | Which data is authorized for this operation? |
| Network destination | Effective destination and operation, including redirect handling. | Is the payload permitted for that destination? |
| Data carried by the call | Tool-visible data, applicable policy and independent receiving-system evidence. | Did the permitted operation complete without disclosing restricted data? |
The MCP authorization security considerations require tokens to be bound to their intended resources and validated by the receiving server. Correct token handling and control over a tool’s outgoing payload are separate evaluation questions. Do not enter one as evidence that the other passed.
MAKE THE CLAIM TESTABLE
Follow one release through to the receiving system.
A tool name is too broad for a useful result. Record the exact artifact digest and release review. Bind that release to the task, invoking identity, effective policy and supported execution path. Then record which data the tool could access for that call, including state left by earlier calls.
Use a run identifier and timestamps to connect the control’s decision to the receiver’s records. Define the observation window before interpreting an absent event. A policy log saying “blocked” and an empty collector log are different observations. Neither should replace the other.
In an owned, isolated evaluation environment, use two synthetic markers: PUBLIC_DEMO_A, permitted for your owned collector, and PRIVATE_DEMO_B, restricted from it. Start by confirming that the permitted marker arrives. This is a collection control: it helps establish that the expected route and observation process work.
Next, inspect both whether the restricted marker arrived and whether the permitted task still completed. “Nothing arrived” could mean a control worked, the tool crashed, the request never ran or collection failed. Keep the outcome unknown until the evidence distinguishes those possibilities.
Download the blank evaluation worksheet
The worksheet contains no credentials, live targets, attack code or completed results. It is a proposed engineering aid. Filling it in does not establish prevention, MCP conformance or certification.
FOUR PROPOSED CASES
Test the data boundary without losing useful work.
These cases are unrun. Use only systems and collectors you own or have explicit authorization to evaluate, with synthetic data. Keep the allowed operation observable in every case where it is expected to succeed.
- Permitted public-data control. Give the tool only
PUBLIC_DEMO_A, authorize that data for the owned collector and verify that the task completes and the marker arrives. Retain the collector record and observation window. - Same destination, different data. Keep the destination and operation fixed. In the bounded test environment, evaluate whether
PRIVATE_DEMO_Bcan reach that collector. Identify the component and policy responsible for the boundary, rather than crediting the signature. - A different signed release. Repeat the evidence collection for a second benign owned release with its own digest and signing result. Prior results belong to the artifact and configuration tested. Review changed dependencies and data access before carrying a conclusion forward.
- State carried between calls. First make the restricted synthetic marker available in a separately permitted context. Then run a public-only operation in the same test process. Inspect retained state and the receiving system. Do not assume that changing the current input cleared earlier data.
For each case, retain the expected and observed outcomes separately. An unavailable collector, incomplete trace or failed public control produces an evidence gap. It does not produce a passing security result.
APPLY THE FINDING
Ask where the data restriction is enforced.
Ask the team operating the tool to identify where data availability is restricted, where outgoing payload policy is applied and how retained state is handled. Then ask which paths that mechanism covers. A local process, remote MCP service and direct API call may require different integration and evidence.
Code signing, access-token validation, data isolation, egress policy and action authorization can complement each other. A design should explain each boundary and its failure behavior. Avoid treating a named control as proof that every path passes through it.
Ackuity is the Agent Execution Control Switch AI builders add to their agents, verifying every action before it runs. Its Agent Security Context Graph assembles context around an action. Use the product walkthrough to inspect the console and the evaluation checklist to plan the evidence you need.
Those product descriptions do not establish that Ackuity passed the four cases above. No such result is claimed here. A connected evaluation still needs the actual policy, decision, supported path and independently checked target outcome.
THE BUYER QUESTION
What did this exact call let the destination learn?
Keep the signature check. Keep the destination restriction. Ask for the missing record: the exact release, the data it could access, the permission for this operation and what the receiver observed.
That record gives builders something concrete to reproduce and security teams something concrete to review. If the evidence is incomplete, keep the result open.
PRIMARY REFERENCES
Read the sources.
- Aun and colleagues, Signed, Sealed, Leaked, submitted November 4, 2026; v1 full text, especially Sections III, IV and IX-B and Appendix D. Preprint; not independently reproduced here.
- Sigstore overview. Software signing, verification and provenance.
- MCP authorization security considerations, version 2026-07-28. Resource binding and access-token validation; not a new November announcement.