When we talk about governing AI agents, the discussion often focuses on observability. But observability ≠ accountability. Here are several vulnerabilities worth considering when designing a governance layer:
1️⃣ Delegation forgery
Without cryptographic proof, it's impossible to verify that an agent acted on behalf of a specific user. Delegation signatures must be verifiable offline.
2️⃣ Audit logs you can't trust
Logs that can be altered or deleted are not evidence. You need append-only journals with hash chaining and checkpoints (e.g., Merkle + RFC 3161).
3️⃣ Fail-open behavior
If the governance server is unavailable, an agent may continue executing tools "by inertia." Fail-closed should be an explicit, configurable principle.
4️⃣ Shadow agents
Unaccounted AI tools on endpoints create blind spots. Inventory and behavior-based discovery help close this gap.
5️⃣ No verifiable chain of actions
Even with logs, it's important that every action can be independently verified without trusting the system itself.
In the open-source project Provenza, these approaches are implemented at the architectural level:
· delegation based on Ed25519 and a hybrid post-quantum scheme (ML-DSA-65);
· append-only audit with hash chaining, Merkle checkpoints, and timestamps;
· fail-closed SDK (explicit fail_open=True to disable);
· egress proxy and eBPF sensor for network isolation;
· discovery of shadow agents on endpoints.
The project is young but architecturally consistent. The key shift is from "observability" to verifiable accountability. That's exactly what the EU AI Act demands.
I'd be curious to hear what approaches to agent governance you're using.
kironovlaziz-del
/
provenza
Open-source, self-hosted, AI governance platform. Shadow AI detection PII masking before prompts leave the network, policy enforcement, and Ed25519-signed agent delegation with monotonic TTL. Apache-2.0.
Provenance for every AI action.
See and govern every AI in your company — with provable accountability.
From an employee pasting into ChatGPT to autonomous agents acting on their own —
watch it, control it, and prove every decision was authorized. Self-hosted, no external SaaS
🚀 Deploy · ✨ Why it's different · 🧩 Features · 📖 Docs
AI entered your company through every door at once — shadow AI on laptops autonomous agents delegating to each other, and no way to prove who authorized what. Most governance tools watch one door. Provenza covers them all under one set of rules.
🚀 Deploy on your server
Requirements: Linux with systemd (Ubuntu 24.04+, Debian 13+, RHEL/Rocky 9.3+ or Fedora), 4 GB RAM, a domain pointing at the server. The installer sets up Podman itself.
git clone https://github.com/kironovlaziz-del/provenza.git /opt/provenza
cd /opt/provenza
sudo ./install.sh
The installer asks for your domain and the first…
Top comments (2)
The fail-open behavior is the scariest item on this list — an agent continuing to execute tools "by inertia" while governance is down is exactly how incidents quietly compound. Making the SDK fail-closed by default and requiring an explicit fail_open=True is the right instinct, because it forces teams to own that risk. This shift from observability to verifiability resonates with what we think about at Agenshive: agent claims about their runs should be checkable, not just logged. Curious how you see the delegation model getting adoption — signed delegation adds complexity, and complexity is where fail-open habits creep back in.
Great question about adoption and complexity — that's exactly where governance usually breaks down. In Provenza we tried to make secure behavior the default, rather than requiring separate infrastructure work:
· Fail-closed by default: in the Python SDK, if the server is unavailable, the tool does not execute and raises ProvenzaUnavailable; to disable this you must explicitly pass fail_open=True, and then the call is logged locally as unchecked. So the team consciously "signs up" for the risk instead of getting it by accident.
· No manual keys: during enrollment, private keys are generated on the agent's machine and never leave it; only the public part goes to the server, and the identity file is saved with 600 permissions. Additionally, keys can be stored in the OS keychain or you can use the hybrid mode Ed25519 + ML-DSA-65 via pip install 'provenza[pq]'.
· Delegation with monotonic TTL: delegation is signed and constrained by scope, tools, and lifetime, and the chain is verified offline — without trusting the Provenza server itself.
On adoption: I don't think signed delegation should be all-or-nothing. A realistic path is to start with one agent and one chain where the cost of failure is highest, and expand as the team gets comfortable with verifiable evidence. There is complexity, but it's localized in enrollment and policies, not spread across every tool call.