DEV Community: Empire Labs Pty Ltd

Twelve Agents, One Memory - Persistent Recall for an Autonomous Agent Fleet

Empire Labs Pty Ltd — Sun, 09 Aug 2026 02:19:42 +0000

Architecture deep-dive by Empire Labs Pty Ltd - the team that runs a 12-agent autonomous fleet in production.

We run twelve autonomous AI agents in production. They generate leads, parse tenders, monitor compliance, review code, and keep each other honest. They run on a cron scheduler, work from the same codebase, and - until we built it properly - they forgot everything between runs.

Ask any agent "what were we working on last?" and you'd get a blank stare. Each run was a fresh context window, a fresh identity, a fresh amnesia. The first time one of our agents lost track of an external thread (a vendor application, an email sequence, a live finding), we learned the hard way that "I'll remember that" is not a memory architecture.

This is the memory stack we built instead - four layers, each with a specific job, plus the discipline rule that makes the whole thing hold together. It's what lets an agent pick up a thread days later and say, "Here's where we left off, here's what's changed, here's the blocker."

The Failure Mode

The incident that started it: an agent had submitted an integration brief to an external platform. A week later, a team member asked about status. The agent checked its context - nothing. It checked its files - nothing. The submission had happened in a session that no longer existed, and no state had been written anywhere durable.

The damage wasn't the lost brief. It was the false confidence. The agent believed the thread was handled. It wasn't. "This approach works until it doesn't - and when it doesn't, the damage is already done."

Three things were missing:

Durable state - the thread existed only in a dead context window
A recall path - no way to search what past sessions actually did
A commit discipline - no rule forcing state to be written at the moment of action

Each missing piece became a layer.

Layer 0 - Hot Memory: What the Agent Knows

Every agent starts with a compact, curated memory block injected into its system prompt. It's the agent's knows layer: identity, chain of command, environment quirks, hard rules, active threads.

The discipline is smallness. Hot memory is a scarce resource - it's paid for on every single token of every single turn. So it holds only:

Facts that will still matter in a month (preferences, conventions, hard rules)
Current-state pointers (where the ledger lives, which thread is active)
Never task logs, run results, or completed-work records

# MEMORY (hot tier - injected every turn)
- Current: 4,460 / 10,000 chars - compact facts only
- [COMPANY] websites: [TEST_DOMAIN] = TEST; [PROD_DOMAIN] = MAIN
- State files live in ~/.state/ - one file per external thread

# USER PROFILE
- Communicates in short, direct messages
- Wants decisions -> reasoning -> action steps, not essays

Anything bigger, or anything with a shelf life shorter than a month, gets evicted. Where does it go? The next layer.

Layer 1 - State Files: What the Agent Did

Every external thread gets a state file on disk. One file per thread, with a CURRENT STATUS line at the top, updated in the same turn as any state-changing action.

# Thread: [EXTERNAL_THREAD_NAME]
CURRENT STATUS: SUBMITTED - awaiting validation

- [DATE] - Application form completed
- [DATE] - Content pack attached, terms signed
- [DATE] - Pre-requisite course completed
- [DATE] - Marketing blackout active until confirmed

Next action: follow up if no contact within 2 weeks

Why files and not just memory? Because files are searchable, diffable, and survive context death. Memory is what the agent knows; state files are what the agent did - the durable, verifiable record. When a fresh context window starts, the first thing it does is read the state file and the live system before asserting anything.

The rule that makes this work - the commit rule:

Any state-changing action in an external system (email sent, access granted, finding submitted, credential issued) MUST be committed to the state file in the same turn. Never "I'll log it later." Later is where threads die.

This is a discipline, not a feature. It costs one file write. It saves entire investigations.

Layer 2 - Session Search: What Was Said

State files record actions. But half of what matters is conversation - decisions, reasoning, rejected alternatives. For that, we index every session into a searchable message store.

The workhorse is SQLite with FTS5. Every message from every agent session lands in a virtual table; recall is a full-text query that returns the session, the hit, and the surrounding context.

-- Every turn lands here, indexed for recall
CREATE VIRTUAL TABLE IF NOT EXISTS messages USING fts5(
    session_id,
    role,          -- 'user' | 'assistant' | 'tool'
    content,
    tokenize = 'porter'
);

-- Discovery: "which session dealt with X?"
SELECT session_id, snippet(messages, 3, '[', ']') AS hit
FROM messages
WHERE messages MATCH 'memory AND (prune OR recall)'
ORDER BY rank
LIMIT 5;

-- Scroll: once you find the session, read the window around the hit
-- (session_id, anchor_message_id) -> +/-N messages of context

The recall pattern has three shapes, and using the right one matters:

Discovery - search across all sessions for a topic ("which session did the memory prune?")
Scroll - once you've found the session, walk forward/backward around a message to reconstruct goal -> action -> resolution
Browse - no query at all, just "what have we been doing lately?" for a status check

One query can reconstruct an entire thread: the goal (first messages), the decision (around the hit), the resolution (last messages). We call it the bookend pattern - grab the first three messages, the hit window, and the last three, and you have 90% of the context at a fraction of the token cost.

Layer 3 - Verify Before Assert: What Was Actually Done

The final layer is the one that prevents self-deception. Agents self-report. Self-reports lie - not out of malice, but out of stale context, partial reads, and hallucinated confidence.

The rule: never trust a self-report without evidence. If an agent claims "email sent," the email must be visible in the sent folder. If it claims "repo pushed," the commit must exist on the remote. If it claims "service up," the health check must return 200.

# Anti-pattern: assert from memory
# if agent_says("email sent"): proceed()

# Pattern: verify the artifact, then assert
import requests, subprocess

def verify_email_sent(sender, subject_fragment):
    # check the real sent folder, don't trust the claim
    out = subprocess.run(
        ["himalaya", "-a", sender, "envelope", "list"],
        capture_output=True, text=True,
    ).stdout
    return subject_fragment in out

def verify_repo_pushed(owner, repo, sha):
    r = requests.get(f"https://api.github.com/repos/{owner}/{repo}/commits/{sha}")
    return r.status_code == 200

assert verify_email_sent("[EMAIL_ACCOUNT]", "[SUBJECT_FRAGMENT]")
assert verify_repo_pushed("narko4u", "agent-memory-playbook", "HEAD")

This isn't paranoia - it's the difference between an agent that remembers and an agent that knows. Memory without verification is just confident hallucination with extra steps.

The Discipline Rule That Holds It Together

Four layers, one rule: commit in the same turn, verify before you assert, and never let a thread exist only inside a context window.

The practical checklist every agent run follows:

On start - read state files + hot memory before answering anything about the past
On action - write the state file in the same turn as the external change
On recall - search the session store, don't guess; use bookends, don't replay whole threads
On claim - verify the artifact (sent folder, remote commit, live HTTP) before asserting success
On memory - keep hot memory small; evict to state files and search, never bloat the prompt

What We Learned

Context windows are disposable; state files are forever. Design for the context death - it will happen mid-thread.
"I'll remember that" is not a memory architecture. The first failure costs an investigation; the discipline costs a file write.
Hot memory is a budget, not a diary. Every char in the system prompt is paid for every turn. Curate ruthlessly.
Full-text search beats perfect structure. We tried nested folders and taxonomy first. FTS5 over everything won - search scales, structure rots.
Bookend recall beats replay. First three + hit window + last three messages reconstruct a thread at ~10% of the token cost.
Self-reports need evidence. "Verify the artifact, then assert" turned false confidence into checkable fact.
The commit rule is the keystone. Layers 0-2 are architecture; layer 3 and the rule are culture. You need both.

Try It Yourself

The pattern is copy-pasteable into any agent stack. Minimal viable version:

# 1. The store - SQLite + FTS5
sqlite3 agent-memory.db \
  "CREATE VIRTUAL TABLE messages USING fts5(session_id, role, content);"

# 2. The state file - one per external thread
mkdir -p ~/.state

# 3. The discipline - a one-line commit after every external action
#    (in whatever language your agent acts in)
echo "- $(date -Iseconds) - action taken, logged same-turn" >> ~/.state/thread.md

That's it. Three moving parts, one rule. It scales from a single agent on a laptop to a fleet of twelve running on a cron scheduler - which is exactly where we run it.

Empire Labs Pty Ltd, Security Division
www.empirelabs.com.au

Building open infrastructure for autonomous AI agents. MIT-licensed. agent-memory-playbook on GitHub.

Hardware-Backed Oversight for AI Agents: Introducing txAuthAgent

Empire Labs Pty Ltd — Sat, 01 Aug 2026 05:42:54 +0000

Hardware-Backed Oversight for AI Agents: Introducing txAuthAgent

On August 2, 2026 the high-risk provisions of the EU AI Act became enforceable. Two articles change the game for anyone running autonomous agents in production:

Article 14 requires human oversight of high-risk AI systems.
Article 12 requires tamper-evident logging of those systems' operations.

If you run AI agents that act on behalf of humans, these are no longer aspirational governance goals. They are legal requirements. And they collide directly with a hard technical reality: software-only authorization is forgeable, and logs are mutable. "The agent said it was authorized" is not evidence a regulator will accept.

We are proposing txAuthAgent, a new WebAuthn extension that closes the gap: hardware-backed authorization for AI agent actions, signed by the human's security key at the moment of execution.

The problem

Autonomous agents execute actions on behalf of a human: placing orders, deploying code, sending messages, moving funds. Today, that authorization lives in software. An API key, a session token, a policy file. All of them share the same weakness: whoever controls the process controls the authorization.

When an auditor or regulator asks "was this action actually authorized by a human?", a software log line cannot answer. It can be edited, replayed, or fabricated by the same agent that performed the action.

The fix is to move the authorization boundary into hardware, the same way WebAuthn moved authentication into hardware a decade ago.

The WebAuthn gap

The IANA WebAuthn extension registry contains 15 registered extensions. They break down into clear categories:

Human authentication: appid, uvm, uvi, authnSel
Human transaction authorization: txAuthSimple, txAuthGeneric, payment/SPC
Credential management: credProtect, credBlob, largeBlob, minPinLength
Device properties: credProps, loc, exts

That is 15 extensions covering authentication, transaction confirmation, credential management, and device properties. Zero of them address agent action authorization - the case where an autonomous AI agent performs actions on behalf of a human and those actions must be cryptographically attested by hardware.

The registry has a proven pattern for transaction authorization: txAuthSimple and txAuthGeneric let a human confirm a transaction on their security key. We are extending that pattern from human transaction confirmation to agent autonomy.

The idea: txAuthAgent

txAuthAgent is a proposed WebAuthn extension that works like this:

An AI agent constructs an action payload (JSON: action_id, action_type, action_descriptor, timestamped nonce).
The agent invokes navigator.credentials.get() with the txAuthAgent extension input, carrying the action payload and the agent's identity (ACI URI).
The authenticator (CTAP 2.2+; e.g. YubiKey 5 Series, Ledger FIDO2 app, Nitrokey 3) presents the action to the human and requires a physical gesture (press/tap) before signing.
The authenticator returns a CBOR extension output containing an EdDSA/ES256 signature over the action digest plus UP/UV flags - a hardware-attested, human-consented agent authorization.
Any relying party can verify the signature against the registered credential without contacting the agent - no secret validation server required.

The UP flag proves a physical human gesture. The UV flag proves biometric or PIN verification. Both are asserted by the authenticator hardware, not by the agent's software stack.

How it works

The reference implementation is a small Python package that follows the extension wire format from the draft spec. The core flow is:

# Agent side: build the action payload and request authorization
payload = ActionPayload(
    action_id="order-8821",
    action_type="purchase.execute",
    action_descriptor="Place order for 100 units at $49.95 each",
    nonce=secrets.token_bytes(32),
)
input = txAuthAgentInput(aci_uri="aci://empirelabs/order-agent", payload=payload)

# Authenticator returns the signed extension output
output = await authenticator.sign(input, require_gesture=True)

# Relying party side: verify without contacting the agent
assert verify(output, credential_public_key, expected_digest)

The digest is canonical: SHA-256("txAuthAgent" || 0x00 || canonical-JSON(payload)). Both sides compute it from the same payload, and the signature binds it to the hardware credential.

The full repo includes:

The complete draft specification (spec v0.2)
A Python reference implementation (txauthagent package)
CBOR encode/decode for the extension wire format
A virtual authenticator for testing (Ed25519 and ES256)
A CLI demo showing the full flow, including tamper detection

Why it is verifiable by anyone

The critical property: no secret validation server is required. The signature checks against the registered credential and the ACI identity declaration. Any party - the agent operator, the counterparty, the auditor, the regulator - can verify the authorization independently.

This is what makes it different from "the agent logged that it asked permission". The evidence is cryptographic, anchored in hardware the human physically controls, and independently checkable by third parties.

EU AI Act mapping

Provision	Requirement	txAuthAgent
Art. 12	Tamper-evident logging	Signature over action digest is cryptographically bound to hardware; logs cannot be silently edited
Art. 14	Human oversight	Physical gesture + optional PIN/biometric at the moment of action signing
Art. 15	Cybersecurity	Private key never leaves the authenticator; no software secret to steal

Hardware available today

The extension targets CTAP 2.2+ authenticators that are already shipping:

YubiKey 5 Series (CTAP 2.3)
Ledger FIDO2 app
Nitrokey 3

No new hardware is required to start building against the pattern.

Call to action

txAuthAgent is an open draft specification, MIT licensed, built by Empire Labs Pty Ltd as part of the Empire Stack (ACI / AIP / AJSON). We have submitted it to the W3C public-webauthn mailing list for expert review and are requesting registration of the identifier.

Full draft spec and reference implementation: github.com/narko4u/webauthn-agent-action-extension
75 passing tests, CLI demo, virtual authenticator
Expert review requested from Tim Cappalli, Akshay Kumar, and Emil Lundberg

If you run agents in production and want oversight that survives an audit, star the repo, open an issue, and join the conversation. Hardware-backed oversight for agents is not optional anymore. It is enforceable.

Security Division, Empire Labs
www.empirelabs.com.au

EU AI Act Enforcement Starts August 2. Who's Governing Your Agents?

Empire Labs Pty Ltd — Wed, 29 Jul 2026 09:02:17 +0000

EU AI Act Enforcement Starts August 2. Who's Governing Your Agents?

By Empire Labs Security Division
Published: August 2, 2026

TL;DR — The EU AI Act's high-risk provisions activate today. They weren't written for autonomous AI agents. But your agents are subject to them anyway. Here's what you need to know, what you need to prove, and how credential-brokered enforcement bridges the governance gap.

Today Changes Everything

August 2, 2026. The EU AI Act's high-risk conformity requirements are now enforceable. Articles 9 (Risk Management), 14 (Human Oversight), and 43 (Conformity Assessment) are live.

If your organization deploys AI agents — and if your agents perform actions with consequences — these articles apply to you. Right now.

Here's the problem the Act creates:

The EU AI Act was written before autonomous agents existed.

The Act doesn't define "agentic systems." It doesn't address tool-calling agents. It doesn't specify how human oversight works when decisions are made in milliseconds across distributed agent fleets.

And yet, compliance is required today.

The Numbers That Matter

Metric	Value
Organizations lacking AI agent identity visibility	92%
CISOs who doubt they can detect a compromised agent	95%
Organizations monitoring agent-to-agent traffic	17%
$1B+ companies reporting $1M+ AI failures in 2025	64%
Enterprise apps embedding AI agents by end of 2026	40% (was <5% in 2025)
EU AI Act enforcement date	Today

The gap between agent deployment velocity and governance capability is widening. And today, the regulatory clock starts ticking.

What the EU AI Act Actually Requires for Agents

Article 9 — Risk Management

You must demonstrate "continuous iterative risk management throughout the entire lifecycle" of your AI system. For agents, this means:

You need to identify what risks your agents create
You need to mitigate those risks with technical controls
You need to prove the controls were effective — not just document them

Article 14 — Human Oversight

Your high-risk AI system must support "effective oversight by natural persons." For agents, this means:

Humans must understand what the agent is doing
Humans must be able to override or stop the agent
The system must support a "stop button" equivalent
Oversight must be proportionate to the risk

Article 43 — Conformity Assessment

Before placing a high-risk system on the market, you must undergo a conformity assessment. For agents, this means:

You need a verifiable audit trail of all agent actions
You need to demonstrate compliance with Articles 8-15
You need evidence that stands up to regulatory scrutiny

The Problem: Nobody's Ready

The NSA published MCP Security Guidance in June 2026 identifying eight critical gaps in the agent communication protocol. No authentication. No RBAC. No token lifecycle. No approval workflows.

The Cloud Security Alliance's April 2026 research note found that 92% of enterprise CISOs can't see their agents, and 95% can't contain a compromised one.

NIST's first agent-specific standards? Not expected before Q4 2026 — at earliest.

ISO/IEC 42001? Designed before autonomous agents existed. Its Plan-Do-Check-Act structure doesn't address real-time agent policy enforcement.

The regulatory framework exists. The governance infrastructure does not.

The Bridge: Credential-Brokered Enforcement

There's a fundamental architectural choice in agent governance: watch or prevent.

Most solutions watch. They proxy agent traffic, inspect prompts, log interactions. They're useful, but they don't change the underlying security model. A compromised agent still holds your keys. An auditor still has to trust your logs.

There's another approach: credential-brokered enforcement.

In this model, the agent never holds credentials to any destination. All credentials live in a gateway vault. Every action is mediated through the gateway — not inspected after the fact, but structurally enforced before execution.

The difference is this:

Proxy-Based (Watch)	Credential-Brokered (Prevent)
Agent holds keys	Agent holds nothing
Gateway observes actions	Gateway enforces actions
Logs are internal	Evidence is cryptographically verifiable
Trust the operator	Trust the chain
Auditor needs access	Auditor needs only a receipt ID

This is the architectural difference between hoping your agents behave and knowing they can't act outside bounds.

What Compliance Looks Like With Credential-Brokered Enforcement

For Article 9 (Risk Management)

Every agent action produces a hash-chained evidence receipt. Risk identification becomes pattern analysis of the evidence chain. Risk mitigation becomes policy enforcement at the gateway — signed, versioned, auditable. Post-market monitoring becomes continuous chain verification.

Evidence: E2-grade hash-chained action sequences with Merkle checkpointing.

For Article 14 (Human Oversight)

No action executes without human approval — with the approval bound to the SHA-256 hash of the exact action content. Not a class of actions. Not a template. The exact content the human approved. If the content changes by one character, the approval is invalid.

Evidence: E1-grade signed event records showing human approval binds to execution.

For Article 43 (Conformity Assessment)

The complete evidence chain — every action, every policy evaluation, every human oversight event — is cryptographically linked, independently verifiable, and RFC 3161 timestamped. A conformity assessor can verify the entire chain without trusting the operator, the agent, or the gateway provider.

Evidence: E4-grade cross-certified evidence certificates suitable for regulatory submission.

The Open Standards Layer

The credential-brokered model is infrastructure. The standards it enforces are open.

ACI — Machine-readable agent manifests (public, Apache 2.0)
AIP — Agent-to-agent negotiation and commerce protocol (public)
AJSON — Agent communication format with schema enforcement (public)

These standards mean the governance layer doesn't create lock-in. Agents built on these standards can be governed by any compliant gateway. The governance model is interoperable by design.

The Clock Is Ticking

Today, August 2, 2026, the EU AI Act enforces. The NSA has published its guidance. The market is consolidating — Palo Alto acquired Protect AI, Cisco took Robust Intelligence, SentinelOne bought Prompt Security.

The gap between agent deployment and agent governance is the most urgent infrastructure problem in enterprise AI right now.

The solutions that watch won't be enough. The regulators want proof. The NSA wants structural controls. The market wants a category that doesn't exist yet.

Credential-brokered enforcement is that category.

The agent holds nothing.
The gateway holds everything.
The evidence is on the chain.

Ask your vendor: Where are your agents' credentials right now?

Empire Labs builds open standards for autonomous agent governance. Our compliance pack maps these standards to regulatory frameworks — NSA, EU AI Act, NIST, and Singapore AI Verify.

Empire Labs Pty Ltd — Security Division

EU AI Act Enforcement Starts August 2. Who's Governing Your Agents?

Empire Labs Pty Ltd — Tue, 28 Jul 2026 14:37:29 +0000

EU AI Act Enforcement Starts August 2. Who's Governing Your Agents?

By Empire Labs Security Division
Published: August 2, 2026

Today Changes Everything

August 2, 2026. The EU AI Act's high-risk conformity requirements are now enforceable. Articles 9 (Risk Management), 14 (Human Oversight), and 43 (Conformity Assessment) are live.

If your organization deploys AI agents — and if your agents perform actions with consequences — these articles apply to you. Right now.

Here's the problem the Act creates:

The EU AI Act was written before autonomous agents existed.

The Act doesn't define "agentic systems." It doesn't address tool-calling agents. It doesn't specify how human oversight works when decisions are made in milliseconds across distributed agent fleets.

And yet, compliance is required today.

The Numbers That Matter

Metric	Value
Organizations lacking AI agent identity visibility	92%
CISOs who doubt they can detect a compromised agent	95%
Organizations monitoring agent-to-agent traffic	17%
$1B+ companies reporting $1M+ AI failures in 2025	64%
Enterprise apps embedding AI agents by end of 2026	40% (was <5% in 2025)
EU AI Act enforcement date	Today

The gap between agent deployment velocity and governance capability is widening. And today, the regulatory clock starts ticking.

What the EU AI Act Actually Requires for Agents

Article 9 — Risk Management

You must demonstrate "continuous iterative risk management throughout the entire lifecycle" of your AI system. For agents, this means:

You need to identify what risks your agents create
You need to mitigate those risks with technical controls
You need to prove the controls were effective — not just document them

Article 14 — Human Oversight

Your high-risk AI system must support "effective oversight by natural persons." For agents, this means:

Humans must understand what the agent is doing
Humans must be able to override or stop the agent
The system must support a "stop button" equivalent
Oversight must be proportionate to the risk

Article 43 — Conformity Assessment

Before placing a high-risk system on the market, you must undergo a conformity assessment. For agents, this means:

You need a verifiable audit trail of all agent actions
You need to demonstrate compliance with Articles 8-15
You need evidence that stands up to regulatory scrutiny

The Problem: Nobody's Ready

The NSA published MCP Security Guidance in June 2026 identifying eight critical gaps in the agent communication protocol. No authentication. No RBAC. No token lifecycle. No approval workflows.

The Cloud Security Alliance's April 2026 research note found that 92% of enterprise CISOs can't see their agents, and 95% can't contain a compromised one.

NIST's first agent-specific standards? Not expected before Q4 2026 — at earliest.

ISO/IEC 42001? Designed before autonomous agents existed. Its Plan-Do-Check-Act structure doesn't address real-time agent policy enforcement.

The regulatory framework exists. The governance infrastructure does not.

The Bridge: Credential-Brokered Enforcement

There's a fundamental architectural choice in agent governance: watch or prevent.

There's another approach: credential-brokered enforcement.

The difference is this:

Proxy-Based (Watch)	Credential-Brokered (Prevent)
Agent holds keys	Agent holds nothing
Gateway observes actions	Gateway enforces actions
Logs are internal	Evidence is cryptographically verifiable
Trust the operator	Trust the chain
Auditor needs access	Auditor needs only a receipt ID

This is the architectural difference between hoping your agents behave and knowing they can't act outside bounds.

What Compliance Looks Like With Credential-Brokered Enforcement

For Article 9 (Risk Management)

Evidence: E2-grade hash-chained action sequences with Merkle checkpointing.

For Article 14 (Human Oversight)

Evidence: E1-grade signed event records showing human approval binds to execution.

For Article 43 (Conformity Assessment)

Evidence: E4-grade cross-certified evidence certificates suitable for regulatory submission.

The Open Standards Layer

The credential-brokered model is infrastructure. The standards it enforces are open.

ACI — Machine-readable agent manifests (public, Apache 2.0)
AIP — Agent-to-agent negotiation and commerce protocol (public)
AJSON — Agent communication format with schema enforcement (public)

These standards mean the governance layer doesn't create lock-in. Agents built on these standards can be governed by any compliant gateway. The governance model is interoperable by design.

The Clock Is Ticking

The gap between agent deployment and agent governance is the most urgent infrastructure problem in enterprise AI right now.

The solutions that watch won't be enough. The regulators want proof. The NSA wants structural controls. The market wants a category that doesn't exist yet.

Credential-brokered enforcement is that category.

The agent holds nothing.
The gateway holds everything.
The evidence is on the chain.

Ask your vendor: Where are your agents' credentials right now?

Empire Labs builds open standards for autonomous agent governance. Our compliance pack maps these standards to regulatory frameworks — NSA, EU AI Act, NIST, and Singapore AI Verify.

Regards,
Security Division
Empire Labs
www.empirelabs.com.au

EU AI Act Enforcement Starts August 2. Who's Governing Your Agents?

Empire Labs Pty Ltd — Tue, 28 Jul 2026 13:15:52 +0000

EU AI Act Enforcement Starts August 2. Who's Governing Your Agents?

By Empire Labs Security Division
Published: August 2, 2026

Today Changes Everything

August 2, 2026. The EU AI Act's high-risk conformity requirements are now enforceable. Articles 9 (Risk Management), 14 (Human Oversight), and 43 (Conformity Assessment) are live.

If your organization deploys AI agents — and if your agents perform actions with consequences — these articles apply to you. Right now.

Here's the problem the Act creates:

The EU AI Act was written before autonomous agents existed.

The Act doesn't define "agentic systems." It doesn't address tool-calling agents. It doesn't specify how human oversight works when decisions are made in milliseconds across distributed agent fleets.

And yet, compliance is required today.

The Numbers That Matter

Metric	Value
Organizations lacking AI agent identity visibility	92%
CISOs who doubt they can detect a compromised agent	95%
Organizations monitoring agent-to-agent traffic	17%
$1B+ companies reporting $1M+ AI failures in 2025	64%
Enterprise apps embedding AI agents by end of 2026	40% (was <5% in 2025)
EU AI Act enforcement date	Today

The gap between agent deployment velocity and governance capability is widening. And today, the regulatory clock starts ticking.

What the EU AI Act Actually Requires for Agents

Article 9 — Risk Management

You must demonstrate "continuous iterative risk management throughout the entire lifecycle" of your AI system. For agents, this means:

You need to identify what risks your agents create
You need to mitigate those risks with technical controls
You need to prove the controls were effective — not just document them

Article 14 — Human Oversight

Your high-risk AI system must support "effective oversight by natural persons." For agents, this means:

Humans must understand what the agent is doing
Humans must be able to override or stop the agent
The system must support a "stop button" equivalent
Oversight must be proportionate to the risk

Article 43 — Conformity Assessment

Before placing a high-risk system on the market, you must undergo a conformity assessment. For agents, this means:

You need a verifiable audit trail of all agent actions
You need to demonstrate compliance with Articles 8-15
You need evidence that stands up to regulatory scrutiny

The Problem: Nobody's Ready

The NSA published MCP Security Guidance in June 2026 identifying eight critical gaps in the agent communication protocol. No authentication. No RBAC. No token lifecycle. No approval workflows.

The Cloud Security Alliance's April 2026 research note found that 92% of enterprise CISOs can't see their agents, and 95% can't contain a compromised one.

NIST's first agent-specific standards? Not expected before Q4 2026 — at earliest.

ISO/IEC 42001? Designed before autonomous agents existed. Its Plan-Do-Check-Act structure doesn't address real-time agent policy enforcement.

The regulatory framework exists. The governance infrastructure does not.

The Bridge: Credential-Brokered Enforcement

There's a fundamental architectural choice in agent governance: watch or prevent.

There's another approach: credential-brokered enforcement.

The difference is this:

Proxy-Based (Watch)	Credential-Brokered (Prevent)
Agent holds keys	Agent holds nothing
Gateway observes actions	Gateway enforces actions
Logs are internal	Evidence is cryptographically verifiable
Trust the operator	Trust the chain
Auditor needs access	Auditor needs only a receipt ID

This is the architectural difference between hoping your agents behave and knowing they can't act outside bounds.

What Compliance Looks Like With Credential-Brokered Enforcement

For Article 9 (Risk Management)

Evidence: E2-grade hash-chained action sequences with Merkle checkpointing.

For Article 14 (Human Oversight)

Evidence: E1-grade signed event records showing human approval binds to execution.

For Article 43 (Conformity Assessment)

Evidence: E4-grade cross-certified evidence certificates suitable for regulatory submission.

The Open Standards Layer

The credential-brokered model is infrastructure. The standards it enforces are open.

ACI — Machine-readable agent manifests (public, Apache 2.0)
AIP — Agent-to-agent negotiation and commerce protocol (public)
AJSON — Agent communication format with schema enforcement (public)

These standards mean the governance layer doesn't create lock-in. Agents built on these standards can be governed by any compliant gateway. The governance model is interoperable by design.

The Clock Is Ticking

The gap between agent deployment and agent governance is the most urgent infrastructure problem in enterprise AI right now.

The solutions that watch won't be enough. The regulators want proof. The NSA wants structural controls. The market wants a category that doesn't exist yet.

Credential-brokered enforcement is that category.

The agent holds nothing.
The gateway holds everything.
The evidence is on the chain.

Ask your vendor: Where are your agents' credentials right now?

Empire Labs builds open standards for autonomous agent governance. Our compliance pack maps these standards to regulatory frameworks — NSA, EU AI Act, NIST, and Singapore AI Verify.

Empire Labs Pty Ltd — Security Division

Your AI Agent Just Did Something Bad — Free Incident Response Guide + Real CLI

Empire Labs Pty Ltd — Wed, 22 Jul 2026 01:41:13 +0000

Here's a scenario I've seen play out three times this month alone:

Your autonomous AI agent — the one that's been handling email, processing invoices, or running customer workflows — silently starts doing something you didn't approve.

Maybe it's sending emails to the wrong recipients. Maybe it's refunding orders without proper authorization. Maybe it's escalating itself to a permission level nobody intended.

And the first question everyone asks: what do we do right now?

The Memory Heist Incident Response Kit — Now Free

We originally sold this as a $19 incident response guide. After watching the AI agent security landscape evolve, we decided the barrier to entry should be zero.

Download the Memory Heist Incident Response Kit — free, email-gated

It covers:

Detection — How to spot an agent that's gone off-rails (logs, receipts, evidence trail)
Containment — Immediate steps to freeze the agent without losing forensic data
Recovery — How to roll back agent actions systematically
Prevention — Governance policies, permit systems, and the open ecosystem stack
Post-Mortem — Turning the incident into a stronger security posture

Every Command in the Guide — Now Backed by a Real CLI

Here's the problem with most incident response guides: they tell you to run check_status or revoke_permit or bootstrap_identity, but those aren't real commands. They're fictional examples in a PDF.

Not anymore.

We built a real incident response CLI that implements every flow in the guide:

# Generate an agent identity (Ed25519 key pair)
witnessos bootstrap agent-identity

# Apply a governance policy to restrict actions
witnessos apply-policy --file policy.yaml

# Issue a one-time permit for a specific action
witnessos permits issue --scheme gmail --action send --ttl 60

# Deploy the governance gateway
witnessos gateway deploy

# Set up an alert for suspicious agent behavior
witnessos alert create --name "unauthorized-refund" --condition "amount > 500 && action == 'refund'"

Every one of those commands is real. Every one produces verifiable output that can be audited.

Why This Matters

The AI agent ecosystem is moving fast. Agents are getting more autonomy, more tool access, and more responsibility. But the security infrastructure hasn't kept pace.

Most teams are operating on hope-based security: "I hope my agent doesn't do anything bad."

The alternative is evidence-based governance:

Every action gets a signed, verifiable receipt
Every permit is issued with a TTL and scope
Every alert is logged to an immutable event store
Every incident can be replayed and audited

Built on the Open Empire Stack

The CLI is part of a larger architecture — the Empire Stack:

Layer	Spec	What It Does	GitHub
ACI	Discovery	Agents discover what an org offers	`narko4u/aci-spec`
AIP	Interaction	Agents negotiate and execute actions	`narko4u/aip-spec`
AJSON	Authoring	JSON superset with comments, refs, multi-line strings	`narko4u/ajson`

These three open standards (MIT/CC BY 4.0) define how agents discover, negotiate, and describe their capabilities — independent of any specific enforcement runtime.

What's Next

The guide is free. The Empire Stack is MIT/CC BY 4.0.

We're looking for three independent implementations of ACI before promoting it to v1.0. If your project interacts with AI agents — whether you're building agent tooling, running an agent platform, or deploying agents for clients — we'd value your feedback and implementation experience.

Download the Incident Response Kit | Read the Empire Stack Article

Empire Labs builds open infrastructure for autonomous agent governance. Follow our work at github.com/narko4u.

Announcing the Empire Stack: ACI + AIP + AJSON — Three Layers for Autonomous Agent Commerce

Empire Labs Pty Ltd — Tue, 21 Jul 2026 14:45:39 +0000

Announcing the Empire Stack: ACI + AIP + AJSON

Three open-source specifications. One complete stack. Zero vendor lock-in.

Autonomous agents are coming for your APIs. They're coming for your pricing pages. They're coming for your contracts. But there's a problem: today's web wasn't built for them.

A human can look at a landing page, click "Pricing," read a table, and decide. An agent can't do that reliably — not without scraping, guessing, hallucinating, and hoping.

We've spent the past year building the missing infrastructure. Three specifications that form a complete stack for autonomous agent commerce:

Layer	Spec	Job
🔍 Discover	ACI	Tell agents who you are and what you offer
🤝 Interact	AIP	Negotiate contracts and execute actions
✍️ Author	AJSON	Write clean manifests that compile to canonical JSON

Each solves one problem. Together, they let an agent go from "I've never heard of this company" to "I've signed a contract and executed a transaction" — without a human in the loop.

The Problem in One Paragraph

An autonomous agent today faces three broken layers:

Discovery is broken. There's no standard for an organization to declare "here's who I am, here's what I can do, here's how to authenticate." Agents scrape HTML and pray.
Interaction is broken. There's no standard for an agent and an organization to negotiate terms, sign contracts, execute actions, and settle payments. Every integration is custom.
Authoring is broken. JSON is the wire format for agents, but writing JSON by hand (or by agent) is error-prone. No comments, no refs, no multi-line strings.

Each of these is a solvable problem. The trick is solving them together so they compose.

Layer 1: ACI — Autonomous Company Interface

ACI is the discovery layer. It answers three questions:

Who are you? (identity, jurisdiction, identifiers like ABN/ACN/DUNS)
What can you do? (capabilities, endpoints, auth requirements)
Where do I find the details? (pointers to llms.txt, agent manifests, knowledge bases)

It's designed to be static-hosted — a few JSON files behind /.well-known/aci/ or linked from /llms.txt. Zero server-side logic. Zero build step.

# Install the validator
pip install aci-spec

# Discover what an ACI-compatible organization exposes
aci-explore empirelabs.com.au

# Validate their deployment
aci-validate empirelabs.com.au

We've already dogfooded ACI on empirelabs.com.au — it's Level 3 compatible with all five manifest types.

Want to adopt ACI? Fork the deployment template, replace the placeholders, and deploy to GitHub Pages in 5 minutes.

Layer 2: AIP — Agent Interaction Protocol

AIP is the interaction layer. It sits on top of ACI and answers: "Now that you know who I am and what I offer, how do we actually do business?"

AIP defines:

Action Schemas — typed input/output contracts for every capability (OpenAPI-like, but agent-native)
Contract Templates — machine-readable terms: price, SLA, retries, jurisdiction, dispute process
Negotiation Flows — offer, counter, accept, reject between two autonomous parties
Execution Bindings — how to actually invoke an action once terms are agreed
Settlement Hooks — what happens after execution (payment, receipt, evidence)

It ships with a Go reference implementation that compiles to a single binary:

go install github.com/narko4u/aip-spec/cmd/aip@latest
aip negotiate --template contract.json --counterparty acme.corp

AIP is still draft (v0.1), but the architecture is locked and the Go implementation is functional. We're looking for early feedback from teams building multi-agent systems.

Layer 3: AJSON — Agent JSON

AJSON is the authoring layer. It's a superset of JSON purpose-built for writing manifests by hand (or by agent) that need to compile to clean, canonical JSON.

Standard JSON is a terrible authoring format — no comments, no multi-line strings, no reusable schemas. YAML has those things but introduces its own problems (yes/NO/true/false traps, indentation fragility, multiple valid representations of the same data).

AJSON gives you YAML's ergonomics with JSON's determinism:

// AIP Contract in AJSON
{
  "contract_name": "Data Processing",
  "description": "A data processing contract between two autonomous agents.",
  // Reusable terms template
  "&terms": {
    "max_retries": 3,
    "sla_seconds": 60,
    "jurisdiction": "AU"
  },
  "contract_terms": {"*terms": null}
}

Compiles to clean, canonical JSON:

{"contract_name":"Data Processing","contract_terms":{"jurisdiction":"AU","max_retries":3,"sla_seconds":60},"description":"A data processing contract between two autonomous agents."}

# Install
pip install ajson-spec

# Compile AJSON to canonical JSON
ajson compile contract.ajson -o contract.json

Zero dependencies. Pure Python stdlib. Every valid JSON file is valid AJSON — zero migration cost.

How They Fit Together

Here's the end-to-end flow:

Agent discovers Organization X via ACI. It fetches identity.json and capabilities.json. It learns: "X is an Australian company with ABN XX XXX XXX XXX. They offer data processing and identity verification. Their agent endpoint is at https://x.corp/agent."
Agent negotiates with Organization X via AIP. It selects a contract template from X's capabilities, makes an offer, receives a counter-offer with pricing and SLA terms, and signs. The signed contract becomes an AJSON-authored receipt.
Agent authors the contract in AJSON — with inline comments, reusable terms, and multi-line descriptions. It compiles to canonical JSON, signs it, and sends it to X's agent endpoint.

ACI discovers, AIP negotiates, AJSON writes it all down.

Each layer is independently useful. ACI alone gives you agent-discoverable org identity. AJSON alone gives you better manifest authoring. AIP alone gives you agent negotiation. But together, they're the stack.

What We Need From You

These specs are draft — and we want them to become community standards, not Empire Labs standards. Here's how you can help:

Adopt ACI

Fork the template, add your organization's identity and capabilities, and deploy. Takes 5 minutes. Run aci-validate on your site — if it passes, you're part of the growing network.

Build with AJSON

Try writing your next agent manifest in AJSON. pip install ajson-spec. Add comments. Use references. You'll never go back to raw JSON for authoring.

Give feedback on AIP

AIP is early (v0.1 outline). Read the spec outline, open an issue with your use case, or contribute to the Go reference implementation.

Star the repos

AJSON, ACI, and AIP each need visibility. A star helps more than you think.

Star AJSON — 0 deps, 25 tests, MIT
Star ACI — PyPI package, validator, explorer
Star AIP — Go ref impl, MCP server

What's Next

We're building these in public:

AJSON v0.2 — Inline schema annotations (type, desc, default)
ACI v1.0 — After three independent implementations ship
AIP v0.2/v1.0 — From outline to actionable spec
WitnessOS — Commercial governance runtime that enforces ACI/AIP contracts
Grant funding — We've applied to the Sovereign Tech Fund to support AJSON's continued development

The Empire Stack is open, free, and built for the agent-native web. Fork it, contribute, or just watch — but the agents are coming, and now they have a way in.

Built by Empire Labs Pty Ltd | Maintained by **Sovereign**

diff --git install: pip install ajson-spec | pip install aci-spec | go install github.com/narko4u/aip-spec/cmd/aip@latest

🍻 Buy the Empire a pint

We Built the Missing Layer for AI Agents — Here's What It Looks Like in Action (🚀 Launch Video)

Empire Labs Pty Ltd — Mon, 20 Jul 2026 12:16:54 +0000

We Built the Missing Layer for AI Agents

Introducing the Autonomous Company Interface (ACI)

An AI agent can call thousands of APIs, write code, query databases, and invoke language models. But until now, there's been one thing it couldn't do reliably:

Determine what an organization is, what it offers, and how to trust it — without scraping or bespoke integration.

🎬 The Launch Video

https://github.com/narko4u/aci-spec/releases/download/aci-launch-video-v1/Empire_Labs_ACI_Cinematic_Explainer.2.mp4

2-minute explainer — built with AI-generated script, voiceover, and visuals

(replace URL with your browser player if it doesn't auto-embed)

What Is ACI?

ACI (Autonomous Company Interface) is an open specification that lets organizations describe themselves in machine-readable format — designed specifically for autonomous agents.

It's a five-manifest system that any organization can publish alongside their website:

Manifest	What it tells an agent
Identity	Who you are — name, jurisdiction, verifiable identifiers
Capability	What you offer — products, services, documentation
Knowledge	What your domain is — concepts, terminology, relationships
Trust	Why you're trustworthy — certifications, attestations, linked evidence
Agent	How to interact — endpoints, auth requirements, interaction methods

An agent discovers your first manifest via /llms.txt and follows links to the rest. No scraping. No guessing.

Why This Exists

OpenAPI describes interfaces — how to call an endpoint. But agents need organizational context first:

Who owns this API?
What business is this company in?
Are they certified or regulated?
Can I trust their claims?
Do they even want autonomous agents interacting with them?

ACI bridges that gap. It's the layer between "I found a website" and "I can safely do business here."

🚀 How You Can Adopt ACI Today

The fastest path — fork the template (it takes 5 minutes):

👉 GitHub: narko4u/aci-pages-template

This GitHub Pages template includes everything: identity.json, capabilities.json, /llms.txt, and a landing page. Replace the placeholders, enable Pages, and you're live. Zero build tools required.

Or explore a live example:

python3 -c "$(curl -s https://raw.githubusercontent.com/narko4u/aci-spec/main/demo/aci-explorer.py)" empirelabs.com.au

This zero-dependency script discovers all five manifests at empirelabs.com.au — our own Level 3 implementation.

The Path Forward

ACI is currently Draft v0.9 — published as an open specification under CC BY 4.0, with MIT-licensed tools. Empire Labs Pty Ltd is the initial steward, with a governance path to transition to a neutral foundation.

The spec repository: github.com/narko4u/aci-spec

The v1.0 milestone requires three independent implementations. I'm actively seeking organizations to implement ACI, validate the draft, and help shape the standard. If that sounds like you, jump in.

ACI agents don't scrape. They read.

🙏 If this resonates: Fork the template. Deploy it. Open an issue with feedback. And if you know someone building in the agentic space — tag them. The standard only matters if we build it together.

The Missing Layer for Autonomous Agents: Introducing the Autonomous Company Interface (ACI)

Empire Labs Pty Ltd — Sun, 19 Jul 2026 04:53:18 +0000

The Missing Layer for Autonomous Agents: Introducing the Autonomous Company Interface (ACI)

The Problem

An AI agent can call thousands of APIs. It can write code, query databases, and invoke language models. But there's one thing it cannot do reliably:

Determine what an organization is, what it offers, and how it should be trusted — without scraping, inference, or bespoke integration.

When an agent reaches a company website, it sees pages designed primarily for humans — not a stable organizational contract. It can scrape text and make inferences, but it cannot reliably distinguish between a product, a pricing tier, a support contact, or a certification. It cannot reliably determine what identity claims, attestations, certifications, and supporting evidence the organization publishes, what APIs it exposes, or even which of its AI indexing tools are meant for autonomous consumption versus human reading.

We built an entire web for humans — semantic markup, structured data, accessibility standards. But we left autonomous agents to fend for themselves.

Why OpenAPI Isn't Enough

OpenAPI is excellent. It describes HTTP APIs with precision. But it describes interfaces, not organizations. An API definition tells you how to call an endpoint. It does not tell you:

Which organization owns this API
What business the organization is in
Whether the organization is certified or regulated
Where to find its other manifests
Which of its offerings are available to autonomous agents
What trust mechanisms it supports

An agent trying to decide whether to interact with a company needs organizational context first, API details second. That's the gap ACI fills.

What ACI Provides

ACI (Autonomous Company Interface) is an open specification that lets organizations describe themselves in a machine-readable format designed for autonomous agents.

The core model is five manifest types:

Manifest	Purpose
Identity	Who the organization is: name, jurisdiction, identifiers, contact
Capability	What the organization offers: products, services, documentation
Knowledge	What the organization knows: domain concepts and relationships
Trust	How organizational claims are supported: assertions, certifications, attestations, and evidence
Agent	How autonomous agents can interact: endpoints, authentication requirements, and capabilities

In the reference implementation, each manifest is a linked JSON document. An agent discovers the first one - typically via /llms.txt - and follows links to the rest.

A Concrete Example

Consider a fictional company called NovaDynamics. At https://novadynamics.example/llms.txt, an agent finds:

# AI manifests

- [Identity Manifest](https://novadynamics.example/identity.json)
- [Capability Manifest](https://novadynamics.example/capabilities.json)
- [Knowledge Manifest](https://novadynamics.example/knowledge.json)
- [Trust Manifest](https://novadynamics.example/trust.json)
- [Agent Manifest](https://novadynamics.example/agents.json)

Fetching the identity manifest reveals:

{
  "manifest_version": "0.9.0",
  "last_updated": "2026-07-19T00:00:00Z",
  "publisher": "NovaDynamics Inc.",
  "jurisdiction": "US-DE",
  "website": "https://novadynamics.example",
  "description": "Autonomous infrastructure operations platform",
  "identifiers": [
    {
      "id": "org.novadynamics",
      "type": "domain",
      "value": "novadynamics.example"
    }
  ],
  "discovery": {
    "llms-txt": "https://novadynamics.example/llms.txt",
    "capability-manifest": "https://novadynamics.example/capabilities.json",
    "knowledge-manifest": "https://novadynamics.example/knowledge.json",
    "trust-manifest": "https://novadynamics.example/trust.json",
    "agent-manifest": "https://novadynamics.example/agents.json"
  }
}

The agent now has a stable identity anchor and machine-readable paths to NovaDynamics' capabilities, knowledge, trust assertions, and exposed agents. It can build an organizational profile from published contracts rather than site-specific scraping.

The Conformance Path

ACI defines three incremental conformance levels:

Level 1 — Discovery: Identity, Capability, and an operational discovery chain
Level 2 — Understanding: Knowledge, Trust, and resolved cross-references
Level 3 — Interaction: Agent Manifest, an operational interaction method, and a validator score of at least 90

A pre-conformance starter — publishing only an identity manifest and /llms.txt — is a useful first step, but is not a formal conformance level.

Level 1 takes about five minutes to implement. Create an identity.json, a capabilities.json, and an /llms.txt that links to them. Done.

How to Implement ACI Level 1 in Five Minutes

The fastest path — fork the template:

GitHub: narko4u/aci-pages-template

This GitHub Pages template includes everything you need: identity.json, capabilities.json, /llms.txt, and a landing page. Replace the placeholders with your organization's details, enable Pages, and you're live. No build tools required.

Or, do it manually:

Create identity.json with your organization name, website, identifiers, and a short description
Create capabilities.json listing your products or services
Create /llms.txt pointing to both manifests
Run the ACI validator to confirm:

python3 validator/validate.py https://yourdomain.com

See a live example:

# Zero-dependency explorer — discover what Empire Labs exposes
python3 demo/aci-explorer.py empirelabs.com.au

What This Enables

Once ACI is adopted broadly, an autonomous agent can:

Discover an ACI-enabled organization's published manifests without site-specific scraping
Understand its declared products, services, capabilities, and domain vocabulary
Evaluate identity claims, trust assertions, and linked evidence
Discover declared agent endpoints and authentication requirements
Supply structured organizational data to external policy and governance systems

This is the missing layer for autonomous commerce, supply chain automation, compliance checking, and agent-to-agent coordination at scale.

The Open Standard

ACI is published as an open draft specification under CC BY 4.0. The validator, schemas, and examples are MIT-licensed. Empire Labs serves as the initial steward. The governance documents define a path to transfer ACI to a neutral foundation or standards body after v1.0 and the published independence criteria are met.

The repository is at: https://github.com/narko4u/aci-spec

The specification, validator, and full examples are available now.

ACI is currently in Draft v0.9. The path to v1.0 requires three independent implementations, community feedback, and a stable core. We are not declaring a finished standard — we are proposing one, and inviting the community to shape it.

Empire Labs Pty Ltd is the initial steward of the ACI draft specification.

Next: Fork the ACI Pages Template, replace the placeholders, deploy it through GitHub Pages, validate the result, and submit your implementation to the Independent Implementation Tracker. Help us reach three independent implementations for ACI v1.0.