Enterprise AI access and security infrastructure
Your AI systems get capability, not custody.
AI Access Gateway sits between the AI systems an organization runs and the enterprise systems those AI systems need to use. It establishes who is calling, decides whether the call is permitted, holds the credential rather than handing it over, and records what happened.
What AAG is
An AI system connects to an AAG-controlled security boundary and receives access to approved capabilities across several enterprise systems without holding the credentials for each downstream system.
The AI system gets capability. It does not get custody. That is the whole of the value proposition; everything below is how it is enforced.
The boundary is called a Gateway. A Gateway is where identity is established, policy is evaluated, credentials are held rather than handed out, and decisions are written down. It is a logical security boundary, not a cluster or a container, and it belongs to exactly one of the businesses whose data is at stake — what that writing-down does and does not cover is set out under how it works.
| Not this | Why the description fails |
|---|---|
| Gateway software | A Gateway is one component AAG manages. Naming the product after it describes the deployment unit instead of the control. |
| An API gateway | An API gateway routes and shapes traffic. AAG decides whether an identified caller may act at all, holds the credentials it does not hand over, and produces the evidence. |
| An MCP gateway | A protocol surface is not the product. AAG’s protocol surfaces may change without the product changing. |
| A connector marketplace | Connector Types are how AAG reaches systems. A catalog is not a security platform. |
| An agent framework | AAG does not build, orchestrate, plan for or host agents. It is the security and governance layer an enterprise puts in front of the ones it already runs. |
Who it is for
Organizations that operate enterprise systems on behalf of other businesses — marketing agencies, managed service providers, consultancies and professional-services firms.
These organizations carry a problem their clients have no way to see or audit: one set of tooling, one set of credentials, and a dozen separate businesses reachable from it. AAG gives each of those businesses its own enforced boundary, and gives the firm one place to govern all of them.
The underlying model is Organization → managed business → Gateway,
so the same structure supports a single enterprise governing its own AI access. Serving
agencies first is the current commercial focus, not a limit of the design.
The problem it solves
An organization that wants AI systems to act on its behalf hits the same four problems for every system it connects.
-
The AI system ends up holding credentials
Every agent, script and platform that needs an advertising account ends up with that account’s credentials, multiplying the number of places a secret exists.
-
Access is all or nothing
A credential that can read campaigns can usually also change them. There is no practical way to grant reading without granting writing.
-
There is no boundary between clients
A firm serving twelve businesses from one set of tooling has twelve businesses’ data reachable from one place.
-
No record of what happened
After the fact there is no attributable record of which AI system did what, to which account, under whose authority.
How it works
A request from an AI system reaches its Gateway, and the Gateway answers four questions before anything touches a downstream system.
AI system
An agent, application, automation or scheduled process. It authenticates as a named identity of its own.
The Gateway
Identity, policy, credential custody and the audit record. One boundary, belonging to exactly one business.
Enterprise systems
Advertising accounts, analytics properties, issue trackers, workspaces — reached with credentials AAG holds.
- Who is calling. Gateway traffic is not modelled as shared or unattributed access: a request that carries no session is refused before a handler is chosen, and every request has to be attributable to one specific caller. An identity is a machine identity here — a human reaches AAG through a different, separately authenticated path, and the two are distinct record types that are never collapsed. Attribution today is to the credential presented rather than to an independently verified caller, because the runtime trusts the platform’s own authentication of the identity in front of it.
- What may it do. Every capability is classified as a read or as a mutation, one by one. Permission to change something is not inferred from permission to read it, and a capability carrying no classification is treated as a mutation rather than as a read.
- Which boundary is it in. One AI session is bound to exactly one Gateway, fixed when the session is issued and never mutated. Reaching a different Gateway requires a different session, the check is made server-side, and no policy may override it.
- What happened. Security-relevant activity is written as a record that can be assembled into evidence for the business whose data it concerns. Once a request has been matched to this Gateway and its token verified, every decision after that point — allowed or denied — is recorded and attributable. Before that point there is no actor to name, and a request refused there leaves no record in this chain at all. That is deliberate rather than missing: the identity presented may belong to a different business, and writing it into this business’s evidence would disclose one customer to another. The consequence is worth stating plainly, because it bounds what the chain can be used for: traffic refused at the door is counted in operational logs and does not appear in the audit evidence a customer is given. Audit records are append-only. A correction is a new event; records are not edited or deleted to change what they say. The evidence store enforces that rather than promising it: a write refuses to overwrite an object that already exists, the identity that writes holds create-and-read and no delete, and the retention policy on this estate has been locked, which puts shortening it beyond an operator and beyond Google. That lock runs for 400 days rather than forever.
The credential itself does not travel this path outward. A connector holds a reference to protected storage, not the secret. No AI caller receives credential material — no token, key, secret, certificate or redeemable handle — at any permission level.
What a customer gets
-
Isolation
A Gateway is a security boundary belonging to exactly one business, and a request authorized in one Gateway is not thereby authorized in another — including two Gateways owned by the same business. The ownership decision behind that is a walk over stored records rather than an inference from a name or a project layout. It is not topology-free, and AAG does not pretend otherwise: the caller identity the walk starts from is established by the cloud platform’s own access control, so the first hop rests on infrastructure and the rest does not.
-
Credential custody
Credentials stay in protected storage and are referenced, not copied.
-
Policy enforcement
Where AAG is unable to determine identity, ownership, the intended account or the authorization answer with confidence, it denies rather than guessing or routing around the uncertainty — an unreachable database, an unreadable policy file, a stale or foreign snapshot and a request carrying no session all end in a refusal. On a Gateway configured with a policy, the absence of a rule permitting an action is itself a refusal. A Gateway deployed without one does not thereby permit more: the grant and capability checks still decide, but the policy layer abstains rather than denying, and that difference is worth knowing before reading “default deny” as universal.
-
Attributable audit
Access decisions, connector executions, credential changes and administrative actions produce records, and a correction is added rather than applied to the original. Which decisions reach the chain, and which are outside it, is under how it works.
-
Evidence on demand
AAG is designed to produce a security evidence package for one business, covering its own posture and no other business’s.
-
Administration and data access
Whether setting a Gateway up should let anyone read what passes through it — and how far today’s estate is from the answer, which is the largest gap AAG has — is set out in the security overview.
What we will not claim
Talk to us
AAG is sold and onboarded directly. There is no self-service signup, because provisioning a security boundary for someone else’s client is not a signup flow.