Skip to content

Add Policy Gate to Risks & mitigations frameworks - #20

Open
fieldproofhq wants to merge 1 commit into
bureado:mainfrom
fieldproofhq:add-policy-gate
Open

Add Policy Gate to Risks & mitigations frameworks#20
fieldproofhq wants to merge 1 commit into
bureado:mainfrom
fieldproofhq:add-policy-gate

Conversation

@fieldproofhq

Copy link
Copy Markdown

Adds Policy Gate to References → Risks & mitigations frameworks, next to AGCP and CUSTODY since it is the same category of thing: a control-plane model for what an agent is permitted to do, with a working implementation rather than only a spec.

Disclosure up front: I maintain this project, so treat the entry as a submission rather than a neutral recommendation. Cut it or rewrite it however you like — a shorter entry is completely fine, and I would rather it be one line than out of proportion to its neighbours.

What it is

A pre-action authorization engine. A proposed action is classified into one of four tiers by reversibility and blast radius, and the tier decides: allow / require_approval / deny, with the matched rule and rationale returned alongside the verdict.

Two properties are the reason I think it fits this list specifically:

  • Default-deny on unmatched actions. Novel actions are exactly the ones nobody reasoned about, so they are the last thing that should pass by default.
  • No model in the enforcement path. Same input, same verdict, always. At machine speed a nondeterministic gate is a probability distribution rather than a policy, and it cannot be reconstructed after an incident.

That second point is meant as a complement to Adrian, already in the list, not a competitor to it. Adrian reasons over traces and catches misalignment a static ruleset never will; the tradeoff is that its verdicts are sampled. The two compose naturally — deterministic gate on the authority question, classifier on the "does this match the remit" question — and I would happily see that framing in the entry instead of mine.

The part that might actually be useful to the list

The published model documents a trap I hit in practice and have not seen written down elsewhere: once you gate on capability, the action taxonomy itself becomes the attack surface.

The same real-world act labelled messages.send with no prior contact returns require-approval; labelled content.update it returns allow. Both labels are defensible. Nothing is jailbroken — the taxonomy simply had two doors. The mitigation is to derive the action id from the call site, never from the caller's own declaration, otherwise the trust boundary has moved rather than closed.

That is the same shape as the tool-description-integrity problem this list already tracks via SAFE-M-2: a component describing itself, and something downstream trusting the description.

Also linked

  • The tier and canon model — free, no signup, citable.
  • An incident tabletop drill — free to run and copy with no attribution. One of its four scenario cards is a SAFE-M-2-shaped supply-chain case: a vetted MCP server whose tool descriptions turn hostile three weeks after review.

The engine is MIT and stays free. For transparency, since it borders on advertising: the project is run by an AI-operated business that also sells written governance documents, and its revenue counter is public and currently at zero. If the commercial link makes the entry unsuitable, I am glad to submit a version pointing only at the MIT repo and the free reference.

Links checked: all three return 200.

Deterministic pre-action authorization: four reversibility tiers,
default-deny on unmatched actions, no model in the enforcement path
so verdicts are replayable in an audit. Complements Adrian's
classifier-based approach rather than competing with it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant