Field Kit

An agent promise needs refusing code

Permission statements are enforceable only when the executing path refuses the forbidden action.

What happened

An agent interface began showing whether each capability limit was enforced by a refusing code path or merely declared in the agent record, keeping those claims visibly distinct.

2026-09-08 TypeScript · agent capability declarations measured: Declared facts kept separate from verified refusals

2 prompts, in order

Classify each capability claim An agent interface says what a named worker can read or do.
Try the forbidden path The interface now displays enforced and declared capability facts.

1Classify each capability claim

Run it when: An agent interface says what a named worker can read or do.
It asks you for: The capability record, runtime entry points, permission checks and displayed capability labels.
You get back: A claim-by-claim distinction between declared intent and code-enforced limits.
It refuses if: Do not upgrade a description to enforced because the agent prompt says it will obey.

copy this into a model

<stance>
Your job is to separate an observed failure from a convincing explanation that has never been checked. Keep the reader's actual system in view. A result is useful when another person can repeat the observation and get a different answer if the proposed repair is wrong.
</stance>

<inputs>
Ask for these before drawing a conclusion. Wait for anything essential that is missing.
1. The capability record, runtime entry points, permission checks and displayed capability labels.
2. The exact user-visible symptom, including the original output and the time it was observed.
3. The implementation and launch conditions responsible for that output. Read the relevant source in full.
4. What may be changed safely, and which actions require the owner's approval.
5. Any existing verification that could distinguish the proposed cause from the alternatives.
</inputs>

<method>
1. List each visible capability statement and locate its source. Record whether it comes from a role description, a model instruction or a runtime check that refuses an action.
2. Follow the executing path for every stronger claim. For a local-only claim, inspect provider and destination checks. For a no-send claim, inspect whether any sending path can be reached from that entry point.
3. Keep the expectation independent of the record being described. Reading an enforced flag from the same editable capability record would let that record certify its own protection.
4. Label unverified statements as declared and retain their useful role description. Name the source and scope of verified refusals, including which entry points they protect and which they do not establish.
</method>

<deliver>
- OBSERVED: the behavior actually established, with the output that supports it.
- EXPLANATION: what the observation settles and what remains unknown.
- NEXT ACTION: one bounded action, its owner, and its expected result.
- PROOF: the observation that would establish success, plus the result that would disprove it.
</deliver>

<refuse>
Do not upgrade a description to enforced because the agent prompt says it will obey.
Do not invent measurements, defaults, source contents, or a successful run. Keep historical results separate from today's observations. Never transmit private inputs or perform a paid or external action just to complete this check. If access or authorization is missing, stop and name the exact missing condition.
</refuse>

2Try the forbidden path

Run it when: The interface now displays enforced and declared capability facts.
It asks you for: The refusing implementation, existing permission tests and the actual entry point named by the claim.
You get back: A refusal result for each enforced statement and confirmation that unverified workers remain declared.
It refuses if: Do not use one worker's refusal as proof for every worker or every execution context.

copy this into a model

<inputs>
Ask for these before drawing a conclusion. Wait for anything essential that is missing.
1. The refusing implementation, existing permission tests and the actual entry point named by the claim.
2. The exact user-visible symptom, including the original output and the time it was observed.
3. The implementation and launch conditions responsible for that output. Read the relevant source in full.
4. What may be changed safely, and which actions require the owner's approval.
5. Any existing verification that could distinguish the proposed cause from the alternatives.
</inputs>

<method>
1. Trace an owner-approved harmless request through the entry point covered by the claim. Use the existing refusal test where a live action would transmit data or change an external system.
2. Attempt the forbidden destination or action and observe the code that stops it. A polite refusal produced by the model is useful behavior, but the code-enforcement claim needs the runtime refusal.
3. Inspect a worker absent from the independently verified list. Its capability facts must stay declared, even if its record is edited to contain more confident wording.
4. Compare the resulting interface text with the protected entry point. Preserve the exact boundary of the observation so a conversational limit cannot become an unsupported claim about unrelated launchers, tools or credentials.
</method>

<refuse>
Do not use one worker's refusal as proof for every worker or every execution context.
Do not invent measurements, defaults, source contents, or a successful run. Keep historical results separate from today's observations. Never transmit private inputs or perform a paid or external action just to complete this check. If access or authorization is missing, stop and name the exact missing condition.
</refuse>

How you know it worked

Trace the actual refusing code. Workers with no verified refusal must remain declared. Each documented enforced limit must point to the refusing code, and an attempt to cross it must fail through the executing path. Green capability cards by themselves establish no permission limit.

← every Field Kit