Govern the AI your team sends out.
The outbound LLM call is your new compliance boundary. Anoman governs every request your org routes through the gateway — which providers, which regions, which models, what data may leave, and what secrets must never leave — and records every decision as compliance proof. This is the compliance boundary, not an agent firewall.
How it works
Every egress decision is made pre-call, and written down
Your team / agent → request hits the Anoman gateway with your org's API key
→ [EGRESS POLICY — enforced pre-call]
1. Provider & region allowed? (org-wide residency)
2. Model & model-class within the ceiling?
3. Data-classification × jurisdiction rule satisfied? (e.g. regulated data → Indonesia only)
↳ deny-by-default. Blocked? 403 returned — never reaches the provider, never billed.
→ [PII MASK] anonymize PII before egress — model sees synthetic values
→ [CREDENTIAL DLP] scan prompt / completion / tool-args for leaked secrets — block or monitor
→ allowed request forwarded to the provider
→ [DE-ANONYMIZE] real PII restored in the response to your app
↳ Every request emits a decision record → provider, region, model, data-class, PII-masked, credential-DLP-hit, decision → exportable as NDJSON. The secret itself is never logged.
Capabilities
What your org admin governs
Org egress policy
One policy across every one of your org's API keys: allowed/denied providers, allowed models plus a model-class ceiling, deny-by-default. Set once by an org admin, enforced on every key.
Region & residency rules
Pin allowed regions org-wide, then layer data-classification × jurisdiction rules — e.g. 'regulated data may only egress to Indonesia'. Cross-border transfer becomes a policy, not a hope.
PII masking before egress
The anonymize-then-de-anonymize round-trip masks PII in the prompt before it leaves for the provider and restores the real values in the response. The model never sees raw PII.
Outbound credential / secret DLP
Scans prompts, completions and tool-call args for leaked secrets — AWS keys, GitHub tokens, private keys, JWTs, Slack / Stripe / SendGrid, high-entropy blobs — including base64, hex and URL-encoded. Blocks or monitors, and never logs the secret itself.
Egress audit log = compliance proof
Every request emits a decision record — provider, region, model, data-class, PII-masked, credential-DLP-hit, decision — exportable as NDJSON. This is the 'show me your egress logs' artifact regulators ask for.
AI-usage inventory
Answer 'what AI does my org run through Anoman?' — models, providers, percentage offshore (region outside allowed), and flagged keys or users — straight from the gateway's own metering.
Enforce vs monitor mode
Dry-run a new policy in monitor mode to see exactly what it would block, then flip to enforce with confidence. No surprise 403s in production.
Managed from the dashboard
Available on Pro and Enterprise. Org admins configure everything from /dashboard/ai-governance — no config files, no redeploys, changes apply across all keys immediately.
Scope & limitations
Honesty is the point. Here's exactly what this does — and doesn't — do.
Egress governance is the compliance boundary for AI your team routes through Anoman. It is deliberately not two other things — and we'd rather tell you than let you find out.
AI that flows through Anoman
Every prompt, completion and tool-call your org sends through the gateway: which providers and regions are allowed, which models, what data may leave under which jurisdiction, PII masking before egress, outbound credential DLP, and the audit log that proves it. Enforced pre-call — a blocked call returns 403 and never reaches the provider.
Not an agent firewall. Not shadow-AI discovery.
It does not block network-path SSRF or cloud-metadata access, and it does not enforce agent capability separation — that is the on-prem Edge Collector, a separate product. And it does not discover shadow AI that bypasses Anoman entirely — that is on our roadmap. It governs what goes through the gateway, nothing more.
Compliance mapping
The egress log is your proof
Regulators and auditors increasingly ask a version of the same question: show me where your AI data goes, and prove you control it. The egress audit log answers that directly, and maps onto the frameworks you already report against.
UU PDP (Indonesia)
Org-wide residency plus data-classification × jurisdiction rules enforce in-region processing and controlled cross-border transfer. The audit log evidences every outbound region.
EU AI Act
Records of AI system usage, provider and model per request give you the traceability and logging obligations expected of deployers.
GDPR
PII masking before egress plus documented cross-border controls and a decision log support lawful-basis and data-transfer accountability.
NIST AI RMF
Deny-by-default policy, enforce/monitor modes and a usage inventory map onto the Govern and Manage functions of the framework.
CISA Zero Trust Maturity Model
Pre-call, deny-by-default egress enforcement at the data boundary advances the Data and Application pillars toward the Optimal tier.
Export it as NDJSON
One artifact, many frameworks. The egress audit log is what you hand an auditor when they ask “show me your egress logs.”
The other half
Two boundaries, two products
The compliance boundary and the agent firewall solve different problems. Use egress governance for what goes through the gateway; use the Edge Collector when guardrails must run inside your own network.
Edge Collector →
On-prem guardrails inside your own network — the agent-firewall half. Raw prompts never leave your infrastructure.
Access Control →
RBAC, SSO, audit and org governance — who in your org can do what, alongside what they can send out.
Why Anoman →
See exactly where egress governance sits in the AI Defense Matrix — and where it deliberately doesn't.
Compliance solutions →
UU PDP, PDPA and the audit log in the context of your regulatory obligations.
FAQ
Common questions
What is AI egress control?
AI egress control governs what leaves your organization when your team sends prompts, completions and tool-call arguments out to LLM providers. Because the outbound call is the point where data crosses a trust boundary, egress control is where your compliance boundary now lives: you decide which providers, regions and models are allowed, mask PII before it leaves, block leaked credentials, and record every decision as an audit artifact. Anoman enforces this pre-call at the gateway — a blocked call returns 403 and never reaches the provider.
Is an LLM gateway the same as an agent firewall?
No — and we won't pretend otherwise. Anoman's egress governance is the compliance boundary for AI your team routes THROUGH Anoman: it controls providers, regions, models, PII and outbound secrets, and produces the audit log. An agent firewall is a different job — blocking network-path SSRF and cloud-metadata access, and enforcing capability separation for autonomous agents. That is Anoman's separate on-prem Edge Collector product, not this feature.
How do I prove AI data residency and cross-border transfer control to a regulator?
You set an org-wide allowed-regions policy plus data-classification × jurisdiction rules (for example, 'regulated data may only egress to Indonesia'), and the gateway enforces them pre-call. Every request then emits a decision record — provider, region, model, data-class, whether PII was masked, whether outbound credential DLP fired, and the allow/deny decision — exportable as NDJSON. That egress audit log is the 'show me your egress logs' artifact regulators ask for under UU PDP cross-border transfer rules, the EU AI Act and GDPR.
What is an egress audit log?
It's an append-only record of every outbound AI request and the governance decision applied to it. For each call it captures the provider, processing region, model and model-class, the data classification, whether PII was masked before egress, whether a credential/secret was detected, and whether the call was allowed, monitored or blocked. It never stores the secret itself. Exported as NDJSON, it is the proof artifact that maps directly onto UU PDP, EU AI Act, GDPR, NIST AI RMF and the CISA Zero Trust Maturity Model.
Does Anoman mask PII before sending prompts to the model?
Yes. Anoman's anonymize-then-de-anonymize round-trip masks PII in the prompt before the request leaves for the provider, and restores the real values in the response your app receives. The model sees synthetic values; your users see the real ones. This is PII masking before egress, applied at the compliance boundary.
What's the difference between the compliance boundary and the Edge Collector agent firewall?
The compliance boundary (this feature) governs AI that flows through Anoman's cloud gateway: org egress policy, PII masking, outbound credential DLP and the egress audit log — your proof of who sent what, where. The Edge Collector is a separate on-prem appliance that runs guardrails inside your own network and is where agent-firewall-style network-path controls belong. They are complementary halves, not the same product. Egress governance also does not discover shadow AI that bypasses Anoman entirely — that is on our roadmap.
Make the outbound call your compliance boundary.
Org egress policy, PII masking, credential DLP and an audit log that proves it — on Pro and Enterprise.