August 21, 2026 · 7 min read

Pre-Execution Authorization: Why Logging After the Fact Isn't Governance

An AI agent is about to wire €250,000 to an unverified vendor. Your observability platform will log this event beautifully — 200ms after the money is gone. Aira would have blocked it before it executed. That's the difference between monitoring and governance.

The Problem with Post-Hoc Observability

The current generation of AI governance tools falls into two categories: observability platforms that trace what happened, and compliance platforms that assess risk in a dashboard. Both share the same fundamental limitation: they operate after the action has already occurred.

For an AI agent sending a Slack message, this is annoying. For an AI agent approving a mortgage, freezing a bank account, processing an insurance claim, or executing a wire transfer, it's unacceptable.

Regulators understand this. The EU AI Act doesn't just require logging — Article 14 mandates "human oversight" that enables a person to "intervene on the operation of the high-risk AI system or interrupt the system." You can't intervene on something that already happened.

How Pre-Execution Authorization Works

Aira's authorize() call sits between the agent's decision and the action's execution. The agent decides what it wants to do, asks Aira for permission, and only proceeds if authorized:

# The agent wants to execute a wire transfer
decision = aira.authorize(
    action_type="wire_transfer",
    details="Send €250,000 to ACME Corp, account DE89370400440532013000",
    agent_id="payments-agent",
    model_id="claude-sonnet-4-6",
    policy="rules + AI + human_approval",
    metadata={
        "vendor_id": "ACME-2024",
        "vendor_verified": False,
        "amount_eur": 250000,
    },
)

# Three possible outcomes:
if decision.status == "approved":
    execute_wire_transfer()  # Proceed — receipt already signed
elif decision.status == "denied":
    log_denial(decision)     # Blocked — nothing happened
elif decision.status == "escalated":
    await_human_approval()   # Held for cfo@acme.com

In this example, three policy layers evaluate the request before anything happens:

Rules engine — "wire > €50K → require_approval" fires immediately
AI evaluator — a separate model assesses the action context and flags "unverified vendor"
Human approval — the action is held for the CFO, who receives an email with a one-click approve/deny link

The €250,000 never moves until all three layers agree. If any layer denies, the action is blocked and a cryptographic receipt records exactly why.

What the Receipt Contains

Every authorize() call — approved or denied — produces an Ed25519-signed receipt:

{
  "receipt_id": "rec_a3f8c9d1",
  "action_type": "wire_transfer",
  "agent_id": "payments-agent",
  "decision": "denied",
  "reason": "Policy violation: unverified vendor + amount > €50K threshold",
  "policies_applied": ["rules", "ai_evaluator", "human_approval"],
  "rule_triggered": "wire > €50K → require_approval",
  "ai_evaluation": {
    "model": "claude-sonnet-4-6",
    "risk_score": 0.94,
    "flags": ["unverified_vendor", "high_amount"]
  },
  "signature": "ed25519:9c4f...a831",
  "timestamp": "2026-08-21T14:30:00Z",
  "rfc3161_token": "MIIRzAYJ...",
  "verify_url": "https://airaproof.com/verify/rec_a3f8c9d1"
}

Anyone — a regulator, an auditor, a court — can verify this receipt at the public URL without an Aira account. The Ed25519 signature proves the receipt hasn't been modified. The RFC 3161 timestamp proves when the decision was made. No competitor offers this.

Pre-Execution vs. Post-Hoc: A Comparison

Consider a real scenario: an AI agent in a lending platform decides to deny a mortgage application. Here's what each approach gives you:

Post-hoc observability: The applicant is denied. Your platform logs the event. An hour later, you discover the model hallucinated a credit score. The denial already happened. The applicant already received the rejection. You now need to reverse the decision, contact the applicant, and explain what went wrong. Under the EU AI Act, the applicant has a right to explanation for this automated decision — and your log shows you had no oversight mechanism in place.

Pre-execution authorization: The agent requests authorization to deny the application. Aira's AI evaluator cross-checks the stated credit score against the metadata, flags a discrepancy, and escalates to a human reviewer. The denial never happens. The applicant is unaffected. The receipt records that the system caught and prevented an erroneous decision — exactly the kind of evidence regulators want to see.

The Gateway Alternative

If modifying your agent code isn't feasible, Aira Gateway provides the same pre-execution authorization as a transparent proxy. Change one URL in your LLM configuration:

# Before: direct to provider
OPENAI_BASE_URL=https://api.openai.com/v1

# After: through Aira Gateway — same API, now governed
OPENAI_BASE_URL=https://api.airaproof.com/gateway/openai/v1

Every LLM call now passes through Aira's policy engine before reaching the provider. Content is scanned for PII, prompts are checked against injection patterns, and responses are receipted — all with zero code changes to your agent.

Why This Matters Now

The EU AI Act's high-risk provisions hit August 2, 2026. DORA has been active since January 2025. The regulatory expectation is clear: if your AI system makes decisions that affect people, you need to demonstrate that you can intervene before those decisions execute.

A Datadog dashboard showing what your agent did last Tuesday doesn't satisfy this. A cryptographic receipt proving you evaluated, authorized, and signed every decision before it executed does.

Start free — 20 governed operations per month. Or read the quickstart.