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

> Source: <https://dev.to/sentinelbeacon1/enforcement-and-audit-are-the-same-act-most-agent-stacks-still-treat-them-as-two-481c>
> Published: 2026-07-28 22:36:51+00:00

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:

**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:

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?

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 [izellhendrieth@sentinelbeacon.tech](mailto:izellhendrieth@sentinelbeacon.tech) or just reply here.

— IZELL HENDRIETH FOUNDER, building SENTINEL BEACON V5

--