Bind TrustOps posture to agent authority

[mdheller]

Purpose

Bind TrustOps receipt outcomes to governed agent runtime authority: tool grants, memory access, autonomous execution, route eligibility, and revocation posture.

Upstream contract PR: SocioProphet/functional-model-surfaces#9
Runtime issue: SocioProphet/prophet-platform#398
Ledger issue: SocioProphet/model-governance-ledger#11
Guardrail issue: SocioProphet/guardrail-fabric#13

Scope

• Consume trustops-receipt.v1 and trust-gate-policy.v1 outcomes indirectly through guardrail/governance records.
• Add authority effects for pass, warn, require-review, quarantine, block, rollback, and revoke decisions.
• Support agent-specific receipt classes: agent-trust, rag-trust, robustness, uncertainty, and explanation.
• Track why authority changed by referencing receipt IDs and policy gate IDs.
• Preserve provider neutrality: no direct dependency on ART/AIF360/AIX360 internals.

Acceptance criteria

• A failing prompt-injection/tool-abuse/memory-leakage receipt can revoke or reduce tool grants.
• A high-uncertainty receipt can require human approval before autonomous execution.
• A passing receipt can restore authority only when policy allows it.
• Agent records cite the governing TrustOps receipt and gate decision.

[Keesan12]

The authority effects make sense.

The edge I'd keep explicit is "a TrustOps receipt says something bad happened" versus "runtime authority actually changed now." If those collapse into one state, audits later can prove posture but not explain why an agent was still allowed to run one more turn.

A small split usually helps:

• receipt outcome = pass | warn | require-review | quarantine | block | rollback | revoke
• authority decision = unchanged | reduced | suspended | revoked
• effective_at and restored_by_policy separate from the raw receipt timestamp

That keeps a high-uncertainty receipt from looking equivalent to a hard tool-abuse finding.

This is close to the runtime-side boundary MartinLoop has been pushing on its public OSS surface (Keesan12/martin-loop): receipt as evidence, authority change as governed decision. If that distinction feels useful here too, I'd value blunt feedback on whether the public MartinLoop examples are too runtime-specific or still transferable.

[mdheller]

Thanks for pointing us at Keesan12/martin-loop. I took a real pass through it. My read: MartinLoop is strongest as a concrete runtime-control implementation for governed AI coding loops. The transferable pattern is not a particular file or API shape; it is the separation between: 1. the run/attempt evidence trail, 2. the policy/admission gate, 3. the verifier result, 4. rollback/restore evidence, 5. and the authority or continuation decision that follows. That distinction is useful and directly relevant to the SocioProphet work. The parts that translate cleanly: - Budget preflight before execution, rather than cost accounting only after the run. - Attempt admission before agent execution. - Failure taxonomy that distinguishes verification failure, scope creep, grounding failure, budget pressure, environment mismatch, and safety leash blocks. - Safety leash treatment for verifier commands, file scope, network/dependency/config changes, and secret-like inputs. - Context-integrity precheck before admission/reasoning. - Rollback boundary and rollback outcome artifacts as evidence, not just a best-effort cleanup. - JSONL / inspectable run records as a practical receipt surface. That said, we did not import MartinLoop code or make it an upstream dependency. That was deliberate, not dismissive. Reason: our estate has different authority-plane boundaries. guardrail-fabric, agentplane, and agent-registry each own different parts of the control loop. Importing MartinLoop directly would couple our governance contracts to a coding-loop runtime implementation and to a TypeScript package surface that is narrower than our target estate. We need provider-neutral, repo-neutral, schema-first contracts that can govern models, RAG packages, agents, functional services, graph activations, and runtime authority decisions. MartinLoop is more runtime-specific, which is appropriate for its product, but not the right dependency boundary for us. What we did take from the review is the architectural seam: - receipt/evidence is not the same thing as authority mutation; - admission is not the same thing as execution; - rollback is not a warning state; - quarantine/block/rollback/revoke need deterministic precedence; - replay must bind the admitted input, not only the output artifacts. That pattern is now reflected in our own work: - guardrail-fabric: monotonic TrustOps outcome → runtime action mapping. - agentplane: SemanticActivationReceipt binds the activation bundle hash, graph snapshot, policy bundle, validator/executor identity, run artifacts, and replay artifact. - agent-registry: receipt_outcome and authority_decision are separated so a receipt says what happened, while authority change remains a governed decision with effective_at, restoration policy, gate refs, and evidence refs. Blunt feedback on MartinLoop: I think the examples are transferable at the boundary-pattern level, but some of the public language still reads very coding-loop-specific. That is good for product clarity, but if you want other governance systems to adopt the pattern, I would make the “receipt as evidence / authority as decision” distinction more explicit in the contracts and docs. I would also consider naming one stable, runtime-independent artifact that downstream systems can consume without needing to understand the whole MartinLoop execution model. Net: we did not copy or import the implementation, but the repo did sharpen the design boundary. The transferable insight is valid: evidence receipts should remain inspectable evidence; runtime authority changes should be separate, policy-bound decisions. Appreciate you reaching out!

…

On Thu, May 21, 2026 at 2:14 PM Keesan ***@***.***> wrote: *Keesan12* left a comment (SocioProphet/agent-registry#17) <#17 (comment)> The authority effects make sense. The edge I'd keep explicit is "a TrustOps receipt says something bad happened" versus "runtime authority actually changed now." If those collapse into one state, audits later can prove posture but not explain why an agent was still allowed to run one more turn. A small split usually helps: - receipt outcome = pass | warn | require-review | quarantine | block | rollback | revoke - authority decision = unchanged | reduced | suspended | revoked - effective_at and restored_by_policy separate from the raw receipt timestamp That keeps a high-uncertainty receipt from looking equivalent to a hard tool-abuse finding. This is close to the runtime-side boundary MartinLoop has been pushing on its public OSS surface (Keesan12/martin-loop): receipt as evidence, authority change as governed decision. If that distinction feels useful here too, I'd value blunt feedback on whether the public MartinLoop examples are too runtime-specific or still transferable. — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBO4IFBOUQMCH2FQ3324GD435BQFAVCNFSM6AAAAACYREDV4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMJRGI4DGNJSHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Keesan12]

The transfer question gets a lot cleaner if the runtime authority change is explicit instead of inferred from receipt evidence. I'd keep one field for what happened and another for who was allowed to make it happen so the chain stays useful after policy churn.

[Keesan12]

The seam I would keep sharp is TrustOps receipt outcomes versus governed runtime authority. If the registry can say this receipt reduced or revoked tool grants, this one required human review, and this one restored authority, operators can reason about policy decisions without conflating the agent with the platform. That keeps the authority record auditable instead of turning it into a generic success flag.

[mdheller]

Update after PR #42 merge.

The TrustOps receipt outcome → agent authority decision seam is now hardened.

Merged surface:

• contracts/trustops/agent-authority-decision.require-review-unchanged.invalid.json
• contracts/trustops/agent-authority-decision.revoke-reduced.invalid.json
• hardened tools/validate_trustops_agent_authority_decision.py
• updated Makefile validation target
• updated docs/trustops-authority-current-state.md

Semantics now enforced:

• TrustOps receipt outcomes remain evidence.
• Runtime authority changes remain governed decisions.
• require-review cannot leave authority unchanged; it must reduce authority and set autonomousExecution=require-human-approval.
• quarantine, block, and rollback must suspend authority, suspend autonomous execution, and block egress.
• revoke must revoke authority, revoke tool/memory/autonomous/route access, and block egress.
• authority_decision=unchanged requires unchanged authority effects.
• Any changed authority decision requires changed effects and authorization evidence.

This addresses the latest review seam: operators can now tell whether a TrustOps receipt reported a posture, whether authority actually changed, when the change becomes effective, and what policy/evidence authorized it.