Decide who uses AI, where it may go, and what may leave.
Role-based access and SSO for your team, and egress governance over every request your org routes through the gateway. An on-prem Edge Collector, for guardrails inside your own network, is planned for enterprise (not yet generally available).
Access Control
Organization & Access Management.
Spin up an organization in one click, invite your team, and assign roles — no sales call. A single API key becomes an AI control plane for your org, with SSO, audit trails, and shared governance across every key and member.
Roles
Five roles, enforced server-side
Owner — full control: billing, team, every key and policy
Admin — manage members, API keys, and guardrail policy
Admin (read-only) — SOC 2-friendly auditor seat: read everything, change nothing
Member — use the gateway, manage their own keys and policies
End-user — governed Copilot-only seat: no dashboard, no key minting
↳ Roles are checked on every mutating request at the proxy layer — not just hidden in the UI.
Capabilities
What the control plane covers
Self-serve organization workspaces
Create an organization from the dashboard in a click, invite teammates by email, and switch between your personal and team workspaces — every resource re-scopes to the active org. Available on Pro and Enterprise, no sales call required.
Role-based access control
Five roles — Owner, Admin, Admin (read-only), Member, End-user — enforced server-side on every mutating request, not just in the dashboard UI.
Team & member management
Invite teammates by email, assign roles, remove or suspend access. Member groups are reusable entitlement profiles: which model tiers, monthly token budget, and guardrail policy a group of members gets.
SSO / SAML
SAML 2.0 single sign-on with Okta, Azure AD, and Google Workspace. Every SSO login is audit-logged. Available on Enterprise.
Audit log & compliance export
Append-only event log of every sensitive action — key creation, policy changes, billing credits, role changes. Cursor-paginated API plus NDJSON streaming export for SOC 2 evidence. Available on Enterprise.
Organization-wide governance
One shared weighted-token pool across all of an org's API keys — no multi-key gaming. Custom per-org rate limits and org-wide guardrail policy groups, managed centrally. Available on Enterprise.
Data-residency controls
Opt-in per-key data-residency lock: a request is refused (403) unless the model's disclosed processing region is within the key's allowed regions — Indonesia-first for UU PDP readiness. Available on Pro and Enterprise.
Why it matters
Governance is the moat, not just volume
A raw API key doesn't know who used it, what it was allowed to do, or which region it should have stayed in. Create an organization workspace on Pro or Enterprise and every key gets an owner, every action an audit trail, and every member group a budget and a policy — the layer that turns Anoman from a routing proxy into an AI control plane you can actually govern, self-serve from day one.
Egress Governance
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 can restrict requests to models processed in a chosen region and control 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.”
Edge Collector · Planned for enterprise (not yet generally available)
Edge Collector.
A planned on-prem appliance, designed to run Anoman's guardrails and reversible PII masking inside your own network. Prompt injection detection and PII anonymization would happen on your infrastructure — only metadata telemetry, never raw prompt or response content, would phone home to Anoman. It is planned for enterprise and not yet generally available.
How it works
Guardrails run on your infrastructure, not ours
Your app → request sent to the Collector, inside your VPC
→ [COLLECTOR — on your infrastructure]
1. Prompt injection scan (on-device ML detector)
2. PII anonymize (NIK, NRIC, MyKad, Thai ID, email, credit card & more)
↳ blocked? Rejected locally — never forwarded, never billed.
→ thin forwarder sends the anonymized request to your LLM provider
→ provider response returns
→ [COLLECTOR] de-anonymize — real PII values restored
→ response returned to your app
↳ Raw prompts and PII never leave your network. Only metadata telemetry (counts, latency, guardrail triggers, license heartbeat) phones home to the Anoman control plane over mTLS.
Capabilities
What runs on your infrastructure
On-prem / in-VPC deployment
A distroless container appliance you run inside your own network or VPC — not a hosted proxy. It sits between your app and the LLM provider, on infrastructure you control.
Local guardrails
On-device prompt-injection detection and PII masking — including Indonesian NIK and Singapore NRIC — run locally on the appliance, before any request leaves your network.
Reversible PII anonymization on-prem
The same anonymize-then-de-anonymize round-trip as Anoman's cloud guardrails, but executed entirely on your infrastructure — the model sees synthetic values, your app gets the real ones back.
Metadata-only telemetry
Only operational metadata — request counts, latency, guardrail trigger counts, license heartbeats — is sent to the Anoman control plane. Raw prompt and response content never leaves your network.
Centrally governed
RS256-signed licensing and a signed policy-bundle sync keep the appliance governed from your Anoman control plane over mTLS — so signature and policy updates roll out without any customer content changing hands.
Distroless & lightweight
Built as a minimal distroless image with a thin, non-streaming LLM forwarder and SQLite-backed local audit log — designed to run alongside your app, not as a heavyweight platform.
Residency, two ways
Regional residency today. On-prem residency with Edge Collector.
These are two different, complementary guarantees — don't confuse them. Most customers only need the first.
Regional residency
Anoman's standard SaaS gateway runs in a Jakarta data center, where traces and usage data are stored, for UU PDP readiness. Each model is processed in its own region, shown on its page. No extra setup required.
See regional data residency →On-prem residency
The Edge Collector is designed to go a step further: your raw prompts and responses would never leave your own network at all — guardrails and PII masking would run on your infrastructure, and only metadata telemetry would be sent to Anoman. It is planned for enterprise and not yet generally available.
Talk to us about your requirements →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.
Where does my data go?
Your prompt is processed entirely inside your own network by the Edge Collector — injection scanning and PII anonymization happen on your infrastructure before the request is forwarded to your chosen LLM provider. Raw prompt and response content is never sent to Anoman's control plane.
What leaves my network?
Only metadata telemetry — things like request counts, latency, guardrail trigger counts, and licensing heartbeats over mTLS. No raw prompt text, no PII, and no completion content is ever transmitted to Anoman.
Which PII does it detect?
The same PII engine used in Anoman's cloud gateway: email, credit card, Indonesian NIK, Singapore NRIC, Malaysian MyKad, and Thai National ID by default (phone, IP address, and URL available as opt-in) — with reversible anonymize-then-de-anonymize round-tripping, all running on-prem.
How is it kept up to date and governed?
Licensing is enforced with an RS256-signed license, and guardrail policy is synced from your Anoman control plane as a signed policy bundle over mTLS — so a signature or policy update rolls out to your appliance without you shipping data anywhere.
Is it self-serve?
No. The Edge Collector is planned for enterprise and is not yet generally available — it has not been deployed or piloted with customers yet. If on-prem guardrails matter to you, talk to us about your requirements. The planned first phase covers request/response calls only, not streaming.