EU AI Act Compliance for AI Agents: What Developers Need to Know

The EU AI Act is now active. If you build or deploy AI agents in the EU, you need to comply. Here is what matters for developers.

What the EU AI Act requires

For high-risk AI systems (which includes many autonomous agents), the Act requires:

• Logging and traceability - Record what the system did and why
• Human oversight - Humans must be able to intervene
• Risk management - Identify and mitigate risks
• Technical documentation - Detailed records of system behavior

The problem for AI agents

Traditional software has predictable behavior. AI agents don't. A LangChain agent might call different APIs, access different data, or take different actions each time it runs. Without governance, you have no record of what happened.

Adding compliance to your agents

Asqav is an open-source Python SDK that handles this. Install it:

pip install asqav

Register your agent and sign every action:

from asqav import Asqav

client = Asqav(api_key="sk_...")
agent = client.create_agent(name="my-agent")

# Every action gets a cryptographic audit record
client.sign(
    agent_id=agent.agent_id,
    action_type="data:read:customers",
    action_id="query-001"
)

This gives you:

• Tamper-proof audit trail with quantum-safe signatures
• Policy enforcement to block risky actions
• Compliance reports you can hand to auditors

CI/CD scanning

The asqav-compliance GitHub Action scans your codebase for compliance gaps:

- uses: jagmarques/asqav-compliance@v1
  with:
    standard: eu-ai-act

It catches missing audit trails and unprotected agent actions before they reach production.

Resources

• Asqav SDK
• EU AI Act compliance page
• Full documentation

Comments

[Ross]

Really useful framing. I especially agree with the point that agent compliance has to become developer-native rather than something added afterwards by a governance team.

One distinction I think matters for AI agents is the difference between:

1. signing/logging that an action happened or was attempted, and
2. enforcing at runtime that the action cannot happen unless it has valid authorisation.

Both are important, but they solve slightly different problems.

For EU AI Act-style requirements like traceability, human oversight, risk management, and technical documentation, an audit trail is essential. But for higher-risk agent actions, I think the execution boundary itself also needs to become deterministic.

For example, if an agent can issue a refund, modify customer data, grant access, deploy code, or call an MCP tool with side effects, the protected service should verify something like:

• Is there proof for this exact action?
• Are the parameters exactly the authorised parameters?
• Is this proof intended for this service/audience?
• Has it expired?
• Has it already been used?
• Was required policy or approval evidence present?

If any of those checks fail, the side effect should not execute at all.

That gives developers a stronger compliance primitive than “we can explain what happened afterwards.” It gives them:

“This action was refused before execution because there was no valid proof for this exact request.”

I think this is especially relevant for MCP, LangChain/LangGraph, and multi-agent systems, where the model-visible tool call is not the same thing as a safe execution boundary. The proof should travel through runtime metadata, headers, or config, not as a normal prompt/tool argument the model can manipulate.

So my mental model is:

• audit/signing gives evidence
• policy gives decisioning
• execution gating prevents unauthorised side effects
• receipts/refusals give the compliance trail

That combination feels like where serious enterprise agent compliance is heading: not just “log agent behaviour,” but “make consequential execution proof-bound.”

I’ve been exploring the execution-gating side of this in an open-source kernel here: github.com/Actenon/actenon-kernel, would be interested in how you think about the boundary between audit signing and pre-execution enforcement.