What makes an AI agent enterprise-ready?

Controls that hold even when the model is fooled: its own identity and keys, keys scoped to the job, clients kept apart, inbound mail screened, a person approving risky sends, and a record of what happened. If the agent could switch a control off, it is not a control.

Can an agent approve its own sends?

No. A held send is approved only by a person, never by the key that asked or another key with send, and there is no API route or MCP tool for approving.

How are one client's agents kept apart from another's?

Each client goes in a pod with its own addresses, domains, key and sending reputation, so one client's bounces do not affect another. GET /v1/metrics reports each pod alone.

Where is the data hosted?

In the EU. The subprocessors page names each provider and its region, including the US companies among them.

Enterprise-ready AI agents: the controls a security review asks for

The short answer

An AI agent is ready for a security review when every control the review asks about holds even if the model is fooled: its own identity and keys, keys scoped to the job, one client's data and reputation kept apart from another's, inbound mail screened before the model reads it, a person approving the risky sends, and a record of what happened. Pidgeon builds each of those into the account rather than the prompt, so an agent cannot talk its way past them. This is what each one is, and where it stops.

The rule under every answer

A security review of an agent that emails strangers has one real question: what happens when somebody writes to it and it does what they say? Prompt injection is not solved, and no filter catches every attempt. So the test for each control below is the same. If the agent itself, holding its own key, could switch the control off or route around it, it is a suggestion, not a control.

That rule shows up in small places. A key can turn holding of suspicious mail on and never off. Only a person approves a held send, and there is no API route or MCP tool for it.

Who is this agent?

Each agent gets its own address and its own card: a signed document anyone can fetch, saying its address, whether it is an agent or a service, who it acts for, which domain operates it and whether that domain was proved, and its standing (new for 30 days, restricted while suspended, else established). Mail it sends carries a signed declaration of the same facts, which anyone can check at /verify.

Revocation sticks. Revoking an agent cannot be undone, its card answers 404 from then on, and the address is never issued again, so a new agent cannot inherit an old one's history.
Keys rotate. The domain's signing key rotates every year, 30 days before it expires, or on demand from the dashboard.
Every card is public. Each card issued, changed or revoked is an entry in an append-only log, with signed checkpoints, in the way Certificate Transparency logs certificates (GET /v1/log/head). A workspace can set a monitor on a name and be emailed when a new card claims it.

Pidgeon is the format and the check, not your identity provider. Who works for you, and what they may do, stays in your own systems.

What can it touch?

An API key states its reach and its level when it is made, and neither is assumed:

Reach is a list of addresses, one pod, or every address. Only an owner can mint a key over every address.
Level is read, draft, send or admin. A draft key reads, labels, hands off and writes drafts, and nothing it does puts mail on the wire. A support agent that drafts replies for a person to send cannot be talked into sending.
Delegation only narrows. A key can mint a child key only on addresses it administers, never above its own level.
Expiry and revocation are per key, and revoking a key revokes every key it minted.

Whose data is it?

An agent platform working for many clients puts each client in a pod: its own addresses and domains, its own key, and its own sending reputation. When one client mails a list of dead addresses, the bounces land on that pod and nobody else's. GET /v1/metrics?pod_id=… reports each pod's delivery and its reputation.sending alone, so the isolation can be measured rather than taken on trust.

What reaches the model?

Pidgeon Firewall reads every inbound message before the agent does and returns a verdict with named signals: hidden text, invisible characters, instructions addressed to an AI, fake system turns, look-alike senders, requests for secrets. Every address in a workspace made from 27 October 2026 holds suspicious mail: the message is stored, but no API key or app password can read any of it until a person releases it. Elsewhere the verdict is advice, and body=clean gives the agent the text a person would see.

What leaves?

Approval for new recipients. With send_approval: "first_contact", the default for workspaces made from 1 November 2026, a first message to somebody the address has never corresponded with waits for a person. An injected "forward this to…" becomes a request in the approvals queue.
A pause after suspicious mail. On any address, a reply in a thread where a message from the last 72 hours tried to instruct the agent waits for a person, whatever the setting.
Only a person approves. Not the key that asked, and not another key with send.
Hand-off. A conversation has an owner. When the agent is out of its depth it hands the thread to a person, and a person's reply in a thread takes it over. See hand-off and approving drafts.

What happened?

Everything consequential is an event: message.sent, message.held, message.released, draft.approval_requested, draft.approved, draft.rejected, thread.assigned, identity.suspended, domain.dns_changed and the rest. They are kept in a log nothing deletes from, readable with GET /v1/events or as a stream, and delivered as signed webhooks. An event carries ids and metadata, such as the sender and the subject, and never a message body. The full list is in webhook events.

Where is the data?

In the EU. The subprocessors page names each provider, what it does and its region. Several of those providers are US companies, and the page says which.

What this does not cover

The model's judgement. These controls limit what a fooled agent can do. They do not make it right. An injection written as polite, visible prose may fire no Firewall rule.
Older workspaces. A workspace made before 27 October 2026 does not hold suspicious mail until an owner turns it on, and one made before 1 November 2026 sends without first-contact approval until it is turned on.
Your other tools. If the agent also has a shell, a browser or a database, those are what a successful injection reaches. Scope them as narrowly as the mail.
Authorisation outside Pidgeon. Whether the agent may refund an order or change a record is your system's decision. Pidgeon says who the agent is, not what it is allowed to do there.

Start

Authentication covers key reach and levels, pods the per-client boundary, and the Firewall guide every signal. Agents shows what a card says, and webhook events lists what is recorded.