AER Police: Aeredium's containment layer for financial agents

Short answer

AER Police is Aeredium's newly named agent-safety product. In the July 2 AMA, Eitan described agents as LLM-driven systems that can autonomously call APIs, use MCP connections, make decisions, and take actions. That matters when the action is financial: a bad prompt, hallucination, compromised tool call, or weak software gate can move funds somewhere irreversible.

The live AERPOLICE website expands that into three operating verbs: Bind, Govern, and Prove. Bind means every agent gets its own AERKey-backed cryptographic identity. Govern means every proposed action is checked against policy before execution. Prove means every decision, approval, and transaction becomes a signed audit record.

The website, ACI self-assessment, report flow, and early-adopter registration are public. The July 9 AMA clarified that the full policy and agent-execution service is not generally available yet and is expected to launch alongside AERKey. The site still provides no public customer names, named partners, adoption numbers, pricing, contract addresses, independent audits, or production usage metrics.

Why agents need containment

Eitan's July 2 explanation draws a useful line between chat apps and agents. ChatGPT, Claude, Gemini, and similar products are interfaces to LLMs. An agent goes further: it uses the model to decide, call tools, write code, query systems, and act through APIs or MCP servers. That autonomy is the point, but it also creates new attack surfaces.

How Aeredium says AER Police fits the stack

The key claim is that agent controls should be enforced at the signing and policy layer, not only in application code. That maps directly to AERKey: threshold signing, policy evaluation inside the signing path, audit trails, selective disclosure, and no complete private key held by one party.

In practical terms, an agent that wants to move funds should not simply hold a wallet key. It should request authorization under policy: limits, whitelisted destinations, velocity controls, approval thresholds, and recoverability rules. In that model, if policy fails, the signing path should refuse the request rather than producing a valid signature.

The July 2 AMA also connects this to Aeredium's throughput thesis. Eitan argued that agents will transact 24/7 and at machine speed, so settlement infrastructure must be instant enough for high-frequency trading, arbitrage, treasury management, stablecoin payments, and cross-border flows.

Where Aeredium enters the flow: the July 9 AMA said AER Police can be used only as an off-chain policy engine, without routing execution through Aeredium. The team also described a separate service for agents that parallels StablePro Wallet functionality while remaining distinct from the human wallet service.

Policy checks, approvals, containment decisions, and audit traces were described as off-chain. A protected action becomes an Aeredium transaction, and therefore consumes AERX gas, only when its execution or settlement is submitted on-chain. The team said Kima-derived interoperability transactions brought onto Aeredium follow that on-chain path.

The audit lifecycle was described as recording the requested signature, its purpose, the policy evaluated, threshold participation, and the resulting action. Albert said that anchoring this record on-chain would be possible, but he and Eitan did not describe it as a current requirement. The public page should therefore not imply that every policy decision or audit event is already anchored to Aeredium.

Albert also said policies run inside an enclave. That is the team's security design claim, not independent proof that policies are immutable. The AMA's stronger statements about complete prompt-injection protection and being "fully covered" should not be treated as verified security guarantees.

Platform mechanics from the AERPOLICE site

The official site is more specific than the AMA. It says AERPOLICE sits between agents and the systems they act on, and that every proposed action becomes a Pact: a signed unit of intent that is evaluated before it touches the outside world.

The platform page also names MCP tools exposed to agents: list_roles, propose_pact, get_pact, submit_transaction, and get_wallet_state. That means the product is being presented as infrastructure an agent can call directly, not just a dashboard for humans.

Agent Containment Index

The ACI page is live as a browser-scored self-assessment. It positions OWASP LLM Top 10 and MITRE ATLAS as attack catalogs, then frames ACI as the companion score for what happens after an attack lands: whether the agent stack contains the blast before money or systems are touched.

The site says the assessment has twelve questions across six scored layers. The first layer, input semantic filtering, is explicitly described as a separate crowded market that AERPOLICE does not provide. The six ACI-scored layers are fail-open behavior, key extraction, approve-then-mutate risk, limits as enforcement, atomicity, and audit tamper-evidence.

ACI is not proof that a project is safe. It is a diagnostic starting point. Treat it as an Aeredium product framework, not an independent certification standard, unless third-party validation appears later.

Evidence limits

• The public AERPOLICE site is live, but it does not publish named customers, named partners, audit reports, production usage metrics, pricing, or contract addresses.
• The live AERPOLICE site says design and distribution partner conversations are open with enterprise software platforms, robotics companies, agent harness/platform builders, and systems-of-record owners, but it does not name those parties.
• The platform and about pages include draft or vision-level labels, so implementation details should be treated as product positioning until formal technical documentation, audits, or deployments are published.
• AER Police is distinct from the earlier, broader MCP/agents roadmap. AER Police is the named product; MCP remains part of the agent tooling context.
• The July 9 architecture explanation came with visible uncertainty about optional on-chain anchoring. Formal technical documentation should supersede the AMA when published.
• Claims of 100% prompt-injection protection or complete coverage are not independently substantiated and are not adopted as this site's wording.

Sources

FAQ