Enforcement and audit are the same act. Most agent stacks still treat them as two.

---

The EU AI Act's high-risk obligations hit full enforcement on August 2, 2026. Article 12 wants a queryable record of every AI-driven decision — including whether each governance intervention was a hard gate or a soft gate.

Here's the part I keep seeing teams miss: most agent deployments produce neither.

They log prompts and completions. That's a record of what the agent said — intent and response. It is not a record of what governance was applied at the moment the agent tried to act. And if your governance layer is a separate observer reading logs after the fact, you're already out of compliance for high-risk systems, because you can't prove the policy was enforced at execution time — only that you noticed something afterward.

So the real requirement isn't "keep better logs." It's this: enforcement and audit have to be the same action. The moment your governance layer checks an agent's proposed tool-call against a policy is the moment the audit record gets created — not reconstructed later from scattered logs.

I've spent the last stretch building exactly this, and I want to share the shape of it — partly because I think the architecture is the interesting part, and partly because I'd genuinely rather pressure-test it against people dealing with this than keep building in a vacuum.

The core idea: a pre-admissibility gate.

Before an agent's tool-call executes, it passes through a gate that:

• Checks the acting agent's current trust score (which degrades on policy violations and recovers on clean behavior, so a repeatedly-misbehaving agent escalates toward isolation automatically rather than getting infinite retries).
• Evaluates the proposed action against policy — and records the verdict as a hard gate (blocked) or soft gate (allowed-with-flag), which maps directly to what Article 12 asks for.
• Writes that verdict into a tamper-evident audit chain in the same step. Not a log file. A hash-linked chain where each record commits to the one before it, so you can't silently alter or backdate an entry without breaking the chain.

The part I went furthest on: the audit chain is post-quantum signed.

Each evidence record carries a real ML-DSA-65 (FIPS 204) signature — not a hash, not a simulation, an actual post-quantum digital signature over the canonical payload. The reasoning: an audit trail's entire value is that nobody can forge or alter it after the fact. "Harvest-now-decrypt-later" is a real concern for anything meant to stand up to scrutiny years later, and I'd rather the signatures still mean something in 2035 than have to re-architect this when the crypto landscape shifts.

I'll be honest about what this is and isn't. It's not certified — I'm not going to claim SOC 2 or a FedRAMP authorization I don't have. It's a working system I've been hardening aggressively (including tearing apart my own "it works" assumptions and re-verifying them under real adversarial testing more than once — which caught some genuinely important issues I'd have otherwise shipped). What I'm most interested in right now is whether the shape of this matches real problems.

So, two honest questions for anyone shipping agents into a regulated context:

1. For your agent deployments, can you currently produce — without a multi-day engineering effort — a queryable record showing why an agent took a specific action and what policy was enforced at that moment? Or is that still a "we'd have to dig through logs" situation?

2. Is the enforce-and-record-in-one-step framing how you're thinking about it, or is your governance still mostly an after-the-fact observability layer?

Genuinely curious where people are on this, especially with the deadline this close. Happy to go deeper on the architecture with anyone interested — reach me at [e-mail] or just reply here.

— IZELL HENDRIETH FOUNDER, building SENTINEL BEACON V5

--