What you can hold us to.
Deterministic enforcement, people in charge of high-risk calls, least privilege and data minimisation. Each principle below is a commitment about how the AASG (Agentic AI Security Gateway) behaves — not a verdict about any regulation.
Principles
- Deterministic enforcement
- Policy decides allow, deny, redact, approval, log-only, or escalation by rule — priority and first-match ordering apply, with deny precedence among contributing matches at the deciding priority. A model never makes the final call on a critical allow or deny alone.
- People in charge of high-risk calls
- Calls that need judgment wait for a person in an approval inbox. The gate holds them; it does not talk itself into releasing them.
- Least privilege
- Operators choose contract scopes. The implementation checks delegated tool permissions, risk, and limits against the parent; it does not infer the minimum access a business task needs.
- Multi-tenant isolation
- Tenant-scoped queries and PostgreSQL row-level security are implemented. Isolation depends on correct identity context, migrations, and database-role configuration; source inspection alone does not validate a deployed installation.
- Data minimisation by design
- Keep the record focused on identity, policy, and decision evidence. Deployment location, retention, and data-protection terms belong in an agreed deployment specification.
- Credential references in evidence
- The design goal is to identify the credential used without copying its secret value into the audit record. Credential storage and runtime use are separate controls to review for each integration.
Where the gateway fits
The AASG gateway focuses on action control. Studio and Discovery add model conversations, governed execution, and inventory; those capabilities do not imply complete coverage of adjacent security categories.
| Category | Why not |
|---|---|
| A prompt firewall or language-model proxy | The gateway governs routed actions through identity, policy, record, and approval. Studio separately implements provider calls and text privacy. |
| A CASB | The gateway focuses on agent tool calls and verified delegation; Discovery inventories configured app and grant evidence. |
| A DLP or SIEM product | Pattern redaction and event trails are parts of the gate, not standalone products; detection analytics belong elsewhere. |
| A generic agent orchestrator | The gateway evaluates permitted actions; Studio also implements bounded orchestration. This does not promise a general multi-turn automation engine. |
| An AI-governance checklist | Checklists document intent. The gate evaluates routed calls at runtime and records decisions with receipt support. |
How we write claims
How these principles act on a single call is on the gateway page; the rules are on the policy page, status on the roadmap, short answers on the FAQ page. To challenge a claim, write to us.
A compact signed receipt names the agent, tenant, tool call, and decision. Current strict-audit receipts also name the audit event. Request and policy metadata live in separate records; a signature does not authenticate all neighboring export fields or prove that an external tool completed the action.
| Rule | What it means |
|---|---|
| Early development | Pages describe a problem and an approach, not a finished product. |
| Labelled status | Built means implemented in the reviewed revision. Page-specific limits and the roadmap distinguish code from verified deployment availability. |
| Labelled demos | Illustrative figures are demo-workspace data, never live telemetry, and never claimed as verified signatures unless actually verified. |
| No invented proof | No customers, logos, metrics, testimonials, prices, or compliance verdicts; no third-party certificates claimed. |
| Named knowledge | Implementation claims name their scope and known limits; deployment facts require separate evidence. |