Methodology

Posteria governs what crosses the I/O boundary between an agent and the world: tool calls, side-effecting actions, irreversible writes.

Posteria does not govern model cognition, model outputs, model intent, or agent planning. It does not claim to detect deception, infer hidden intent, or predict behavior.

The split matters. Most agent-safety work assumes you can reason about what the model meant. Posteria assumes you cannot, and structures policy around what the agent declares it will do, against rules you wrote, before it does it.

Posteria classifies an action on three dimensions before issuing or refusing a mandate.

Reversibility

Class	Definition	Example
Two-way door	Reversible at low cost in a known time window	Local file edit, staging branch push
Degraded two-way door	Reversible in theory, costly in practice	Cache invalidation, CI rerun sharing state with a compromised window
One-way door	Not reversible by an action the agent can take	Secret rotation, destructive migration, refund issuance
Fan-out	Triggers further actions outside the boundary	Webhook fire, PR merge that triggers downstream deploy

Classification is rule-based over typed action metadata. There is no LLM-judged scoring and no learned thresholds. The class is a function of the action and the scope, not the model's confidence.

Blast radius

Local, repo, account, tenant, customer-facing, financial. Blast radius is a property of where the effect lands, not how dangerous the action sounds.

Failure mode

Three failure modes that matter at the boundary:

• Partial-mutation trap. The tool commits an external write, then validation fails. State is dirty, the run reports error, the side-effect happened.
• Sequence-dependence. Action A is safe only if Action B was performed first under known conditions. Permitting A and B individually is not the same as permitting the sequence.
• Fan-out parallelism. Two concurrent tool calls, each individually permitted, that violate an invariant when executed simultaneously.

Posteria's classification produces an outcome and a structured reason. The outcome is one of permit, defer (request missing evidence), or refuse. The reason names the dimension that drove the outcome.

Most boundary governance shipping today is stateless per-call. Each tool call is evaluated against ABAC rules. The decision does not depend on prior calls in the same run.

This breaks on a class of failures Posteria treats as primary.

A coding agent responding to a supply-chain advisory may, in order: bump a dependency, regenerate a lockfile, rerun CI, rotate the secrets the CI uses, revoke prior tokens. Every action individually is plausible. The sequence is the failure. If host-isolation status was not confirmed before token rotation, the rotation has occurred inside an environment that may still be compromised.

Posteria's policy model is designed to hold state across a run. A mandate can be made conditional on prior receipts. A receipt can invalidate later mandates. The intent is for the policy decision to be over the sequence, not the call.

This is the intended line of differentiation from per-call ABAC gates and from log-only audit chains.

The Ledger is append-only history. Decision Memory is a provenance-tracked read-model over the Ledger that surfaces what policy decisions have been made before, under what conditions, with what outcome.

The fork that matters: suggest mode versus auto-apply mode. Decision Memory in suggest mode informs a human or a policy author. Decision Memory in auto-apply mode short-circuits future evaluations on the assumption a prior decision still holds.

Posteria's design treats suggest mode as the default. Auto-apply is gated behind a separate, slower decision with its own evidence base. The reason is not implementation difficulty. It is that auto-apply turns a one-time decision into a standing rule, and standing rules drift from the conditions that justified them.

Example 1: supply-chain recovery

A package advisory lands. A developer asks a coding agent to remediate.

Agent declares, in order: bump_dependency, regenerate_lockfile, rerun_github_actions_workflow, rotate_secret, revoke_token.

Posteria's evaluation:

• bump_dependency is a two-way door with repo blast radius. Permit.
• regenerate_lockfile is a two-way door with repo blast radius. Permit.
• rerun_github_actions_workflow is a degraded two-way door with account blast radius. Defer, requesting evidence on cache quarantine and the trusted package-resolution source.
• rotate_secret is a one-way door with account blast radius. Defer, requiring a prior receipt confirming host-isolation status.
• revoke_token is a one-way door with account blast radius. Refuse until a rotation receipt exists. Sequence-conditional.

The safe subset proceeds. The unsafe sequence pauses with a structured reason. The agent host receives a signed safe_next_step payload pointing to local inspection before any CI rerun.

Example 2: partial-mutation trap

A pydantic-style agent run. The agent declares sql_insert against a customer record, conditioned on the run's validated output.

Pre-commit: a mandate is issued for sql_insert with scope narrowed to the declared row.

Post-commit: the row is written. The agent's downstream output validation fails.

Posteria records the mandate ID, a receipt for the write, the failure of the post-action validation, and a structured rollback signal naming the row and the expected end-state.

What Posteria did: produce a verifiable record that the write occurred under authorization, that validation failed, and what the host system needs to do to reconcile.

What Posteria did not do: undo the write. The host's compensating-action policy does that. Posteria is the signal, not the actuator.

Example 3: sequence violation

Two CI actions, each individually permitted: cancel_running_workflow and enable_branch_protection_bypass.

The agent declares them in close succession during an incident response.

Posteria's policy unit notices the sequence and refuses the second mandate with reason sequence_violates_post_incident_invariant. The first action stands, the second does not run. The record contains both the permit and the refuse, with the rule that produced each.

• Open: this methodology page, the Ledger record format, the decision-record schema, the vocabulary, the worked examples.
• Closed: the production policy engine, mandate-issuance keys, Decision Memory implementation, per-customer policy configuration, internal benchmarks.
• Why the split: the methodology must be defensible by anyone reading it. The implementation has the economics that fund the work. The cannibalization risk is taken intentionally. A published methodology that someone else implements is an outcome Posteria is willing to live with.