DEV Community

Cover image for Building AI agent governance: architecture decisions and what I learned
JoudIsmail
JoudIsmail

Posted on

Building AI agent governance: architecture decisions and what I learned

I work in IAM by day. This post is about a side project that started as a fix for a local AI annoyance and grew into something more substantial.

How it started
I was using OpenClaw for local AI work. The problem: it loads the full context on every single request regardless of the task. Ask it to summarise one document and it loads all 50. On a local 14B model that is not workable.

The fix seemed simple: classify intent first, then pull only the context that matches. A compliance question should pull compliance documents. A coding question should pull code files. Not everything.
While building that, I kept thinking about another problem I see at work.

The governance gap I work around every day
Identity governance tells you who the agent is and what it can access. I found relatively few tools focused on preserving a detailed record of what the agent actually did, what it knew at decision time, and who was responsible for each action.
DORA's operational resilience requirements are making this more pressing. Enterprises are deploying AI agents into operational workflows and risk teams are starting to ask harder questions. Not "did the agent have permission?" but "what did it actually do and can you prove it?"
So I combined both problems into one tool.

Architecture: the proxy approach
The core insight: put governance at the proxy layer, not in the application.
Instead of asking every team to instrument their AI code, you sit a proxy between them and the LLM. Every call goes through. Every call gets audited. The only change on the application side is swapping the base URL or wrapping the client.

from eudora import wrap_openai
client = wrap_openai(OpenAI(api_key="sk-..."), proxy_key="eudora-proxy-...")
Enter fullscreen mode Exit fullscreen mode

Everything else stays identical.

DLP at the AI layer
Developers regularly paste credentials into AI assistants when debugging. AWS keys, database passwords, private keys. The model helps, the session gets logged, and the credential has left the building in ways nobody tracked.

The sanitiser runs before every request and checks 15+ patterns: AWS access key IDs, PEM private keys, GitHub tokens, database connection strings with credentials, JWT tokens, Stripe keys, Slack tokens, high-entropy hex strings.
When it detects a credential the request is blocked or flagged, the credential is replaced with [CREDENTIAL REDACTED] in the sanitised version, and an audit event is logged with the pattern type but not the secret value. The secret never reaches the model.

SQLite as the audit store
I chose SQLite with append-only enforcement via database triggers. No separate database process. Audit events are inserted and can never be updated or deleted. SHA-256 of the log content is stored and verified on export.
For a governance tool this is actually the right choice. The audit log needs to be provably tamper-resistant. SQLite with write triggers and a hash chain is simpler and harder to mess with than a Postgres setup that requires careful ACL management.
The human accountability chain
The hardest thing I built. Regulations like DORA require human accountability for AI decisions, which means tracing every agent action back to a named human owner.
This sounds simple until you have agents owning agents owning other agents. The implementation walks an ownership graph, detects cycles, handles multi-hop chains, and verifies that the chain terminates at a human user in the same tenant.
A chain like "Sub-Agent owned by Main Agent owned by alice@company.eu" resolves correctly. A cycle or an unresolved chain gets flagged.

Per run decision traces
The most useful thing the tool produces is not the aggregate dashboard. It is the per run trace.

Run #4821 - 2026-06-05 14:23:11
Agent: Compliance Analyst (alice@company.eu, verified)
Intent: compliance (0.94 confidence)
Context: 2 files loaded
Security: CLEAN - risk score 8/100
Guard: ALLOWED
Scope: COMPLIANT
Output: 847 tokens, 2341ms
Decision hash: sha256:a7f3c2...
Enter fullscreen mode Exit fullscreen mode

Auditors and risk teams want to see what the agent knew and decided, not just that it ran. This is the artifact that closes that gap.

Open core and data sovereignty
Enterprise buyers in regulated industries often cannot send their audit data to a vendor-managed cloud. Self-hosted had to be a first-class option.
Self-hosted gets all features, MIT licensed, free forever. Cloud adds managed infrastructure and EU data residency.

What is next
The project is at Eudora.
If you work in regulated industries and are thinking about AI agent governance, I am interested in what the problem looks like from your side. Particularly around Microsoft Copilot and Azure OpenAI, which are areas I have less direct access to test with.

Top comments (0)