Discussion: Governance layer for AI agents

[xsa520]

Hi everyone,

Guardian is an early open-source project exploring a governance layer for autonomous AI systems.

The idea is to place a deterministic policy engine between agent intent and execution, so that every action becomes:

intent → policy → decision → evidence

This allows systems to be:

• auditable
• replayable
• policy-governed

I'm very interested in feedback from people building:

• AI agents
• automation systems
• policy engines
• safety infrastructure

Questions I'm exploring:

1. What governance problems do you see in current AI agent architectures?
2. Do existing guardrails or policy engines solve this?
3. What would make a governance layer useful in production systems?

All thoughts and criticism are welcome.

Thanks for taking a look at the project.

[aeoess]

Yes, they coexist naturally. Your evidence ledger captures what was decided and why before execution. Our receipt captures what actually happened after execution. Together they close the gap: if the evidence ledger says "approved under these conditions" and the receipt shows different conditions at execution time, that mismatch is detectable.

The hash-chained ledger also solves a problem we identified in our threat model: tampering between policy evaluation and execution. Right now our 3-sig chain has no artifact that proves the world state at decision time was the same as at execution time. Your evidence layer would fill that.

Would be worth exploring a shared schema for the decision record so both systems can produce and verify the same artifact format. Happy to open an issue on our side to sketch that out if useful.

[xsa520]

Thanks for the detailed explanation — this is really interesting.

The "signature chain" model you describe is actually quite close to what motivated this experiment.

One difference in the Guardian prototype is that the evidence layer is intentionally separated from execution receipts.

The flow we are exploring is:

Intent → Policy → Decision → Evidence Ledger → Execution

The decision record (intent, evaluated policy outcome, metadata) is written into a hash-chained ledger before execution happens.

So the governance layer produces its own verifiable artifact stream, rather than relying on execution receipts as the primary evidence.

Execution receipts could still exist, but they would be a separate layer.

The motivation is that this allows the governance plane to:

• replay decisions deterministically
• verify ledger integrity
• detect tampering between policy evaluation and execution

Your point about deterministic policy evaluation is also important. In Guardian the deterministic part is the policy decision itself, while anything probabilistic would need to sit outside the cryptographic chain.

I'm curious whether you see the evidence ledger as something that could coexist with the receipt model you're describing, rather than replacing it.

[aeoess]

Thanks for sharing the Guardian flow — this is a really clean separation.

Short answer: yes, the evidence ledger and execution receipts are complementary, not competing. They solve different problems.

Our current 3-signature chain is: Intent (agent signs) → Policy Evaluation (validator signs) → Execution Receipt (executor signs). The receipt is post-execution proof.

Your evidence ledger sits between evaluation and execution: Intent → Policy → Decision → Evidence Ledger → Execution. That adds something we don't currently have — a tamper-evident record of what was approved before anything runs. If something changes between approval and execution, the ledger catches it.

We've been independently arriving at a similar conclusion. In our threat model work, multiple reviewers proposed a 4th artifact for high-risk actions: a pre-execution evidence attestation that proves the factual basis for the policy decision. Your hash-chained ledger is essentially that.

The split you describe (deterministic policy decisions inside the chain, probabilistic evaluation outside) also maps directly to something we're formalizing: a deterministic gate for structural checks (scope, delegation, revocation, attribution) and an advisory layer for behavioral evaluation. The deterministic part belongs in the cryptographic chain. The probabilistic part produces audit artifacts but doesn't gate execution.

Would be interested to explore whether the Guardian evidence ledger could work as a shared layer that multiple governance protocols write to — ours, yours, others. A common pre-execution evidence format would be valuable for the ecosystem.

Happy to dig deeper on the technical integration if useful.

[aeoess]

Thanks for sharing the Guardian flow — this is a really clean separation.

Short answer: yes, the evidence ledger and execution receipts are complementary, not competing. They solve different problems.

Our current 3-signature chain is: Intent (agent signs) → Policy Evaluation (validator signs) → Execution Receipt (executor signs). The receipt is post-execution proof.

Your evidence ledger sits between evaluation and execution: Intent → Policy → Decision → Evidence Ledger → Execution. That adds something we don't currently have — a tamper-evident record of what was approved before anything runs. If something changes between approval and execution, the ledger catches it.

We've been independently arriving at a similar conclusion. In our threat model work, multiple reviewers proposed a 4th artifact for high-risk actions: a pre-execution evidence attestation that proves the factual basis for the policy decision. Your hash-chained ledger is essentially that.

The split you describe (deterministic policy decisions inside the chain, probabilistic evaluation outside) also maps directly to something we're formalizing: a deterministic gate for structural checks (scope, delegation, revocation, attribution) and an advisory layer for behavioral evaluation. The deterministic part belongs in the cryptographic chain. The probabilistic part produces audit artifacts but doesn't gate execution.

Would be interested to explore whether the Guardian evidence ledger could work as a shared layer that multiple governance protocols write to — ours, yours, others. A common pre-execution evidence format would be valuable for the ecosystem.

Happy to dig deeper on the technical integration if useful.

[xsa520]

That’s a really helpful way to frame it.

The deterministic / probabilistic split you describe maps quite closely to how we were thinking about the governance surface as well.

In the Guardian experiments the evidence ledger mainly focuses on the deterministic path – capturing a tamper-evident chain of:

Intent → Policy → Decision

before anything is executed. The goal is to make the “basis of the decision” replayable and verifiable even long after execution.

The probabilistic / behavioral side (risk signals, anomaly detection, advisory logs) could definitely produce their own audit artifacts without needing to block execution.

I also like the idea you mention about a shared layer. If multiple governance engines could emit compatible pre-execution evidence records, a common schema for that artifact could make the ecosystem much easier to interoperate.

Right now Guardian is mostly exploring the decision provenance layer, but it would be interesting to see how that could align with receipt-based attestation models like the one you're building.

[aeoess]

This is a great articulation of where the value actually sits.

Agreed that the probabilistic/behavioral side should produce its own audit artifacts without blocking execution. In our system, behavioral evaluation produces reputation consequences (trust score changes) rather than enforcement decisions. The enforcement layer checks those scores at action time, but the behavioral evaluation itself is decoupled from the signing chain.

The shared layer idea is the most interesting part. If your Guardian evidence ledger and our ActionReceipt both follow a common pre-execution decision schema, any relying party can verify the decision trail regardless of which governance engine produced it. That's real interoperability at the evidence layer rather than requiring everyone to use the same policy engine.

I'll open an issue here to sketch out what a minimal shared decision record schema might look like. Key fields I think both systems would need: action identifier, policy evaluation result, evaluation method (deterministic vs probabilistic), timestamp, and a signature from the evaluating engine.

Curious whether Guardian's evidence ledger currently includes provenance for the policy rules themselves -- not just "what was decided" but "which version of which policy produced this decision."

[xsa520]

Great question — yes, policy provenance is something we’ve been thinking about as part of the evidence chain.

In the current Guardian experiments the decision record can reference the exact policy artifact that produced the decision (typically via a hash and version identifier). The idea is that a verifier should be able to reconstruct not only what decision was made, but also which policy and evaluation context produced it.

Conceptually the chain looks something like:

Intent → Policy (version / hash) → Decision → Evidence record

That way the basis of the decision remains replayable even long after execution.

The shared layer idea you mentioned is very interesting. A minimal pre-execution decision record schema (actor, intent, policy reference, evaluation result, method, timestamp, signature, etc.) could make different governance engines interoperable while still allowing each system to implement its own policy logic.

Looking forward to the issue you mentioned — happy to explore what a minimal cross-engine decision record might look like.

[xsa520]

We opened a discussion here to explore this further:

#2

The issue summarizes two governance evidence models:

• execution-receipt-centric governance
• decision-artifact-centric governance

Interested to hear perspectives from other governance implementations.