You already govern who logs in. Now govern what your agents can know.
The Context Gateway decides which context an AI agent may receive, on whose behalf and for what purpose, and records exactly what it saw. It sits between agents and the data sources you already run, and enforces identity, delegation, purpose, redaction, revocation and audit on every request.
Nine gaps between identity and data
Agents typically reach data through shared service accounts and API keys with no user, purpose or delegation attached. Neither the identity stack nor the search and data platforms close these gaps alone.
Over-privileged agents
Today · Agents query sources with a service account or shared key that sees far more than the invoking user.
Gateway · Every request carries the user's entitlements, narrowed to what the agent itself is approved for.
Lost delegation chains
Today · User to agent A to agent B: by the second hop the source sees only agent B.
Gateway · Preserves the full chain so policy and audit apply to the whole path.
No purpose binding
Today · Access asks only “can this person see it,” not “for which task.”
Gateway · Binds each request to a declared purpose and checks it against policy.
Inconsistent enforcement
Today · Each search tool, warehouse and MCP server enforces permissions its own way.
Gateway · One policy plane across every connected source.
Sensitive data reaching external models
Today · Regulated fields flow into model prompts.
Gateway · Redacts or tokenizes by data class and by the model the agent may use.
Slow revocation
Today · Long-lived tokens and cached context keep working after an agent is disabled.
Gateway · Revocation takes effect on the next request.
Exfiltration via prompt injection
Today · Retrieved content tells the agent to send data to an external tool.
Gateway · Labels packets with source and sensitivity, and blocks disallowed flows, such as HR data to an email tool.
No record of what the agent knew
Today · After an incident, no one can reconstruct the agent's inputs.
Gateway · Writes a record per packet: who, for whom, why, which source, what was returned and redacted, which policy allowed it.
Unattributed context cost
Today · Token spend on context cannot be traced to an agent, team or user.
Gateway · Per-agent token caps and usage attribution.
Verify. Decide. Fetch and filter. Record.
The agent never reaches a source directly. The gateway holds the only source credentials, and every packet is recorded before it returns.
- STEP 1
The agent presents a Keel token
It carries the user, the agent identity, the delegation chain and a declared purpose.
- STEP 2
The gateway checks the Registry
Is the agent known, owned and approved for this source?
- STEP 3
Policy decides
Allow, deny, allow with redaction, or require approval.
- STEP 4
Scoped call to the source
The gateway uses downscoped, short-lived credentials, never the agent's broad key.
- STEP 5
The response is filtered
Fields are redacted or tokenized, the packet is labeled with source and sensitivity, and it is trimmed to the agent's token cap.
- STEP 6
Delivered and recorded
The packet goes to the agent. The audit record goes to the Keel Intelligence ledger.
{
"sub": "user:nurse.reviewer",
"act": {
"sub": "agent:formulary-lookup",
"act": { "sub": "agent:claims-assistant" }
},
"authorization_details": [{
"type": "context_access",
"purpose": "prior-auth-review",
"sources": ["formulary", "chart-notes"]
}],
"exp": "now + 5 minutes"
}sub is the person. act records each agent acting on their behalf, using the standard OAuth token-exchange format.
Delegation, end to end
The token names the person, each agent in the chain, the purpose and the scope. Most systems only see the last agent. Keel keeps the person and the purpose attached the whole way, which is what auditors and regulators ask for.
Each request is decided on identity, registration, purpose, data class and token budget. A typical outcome: allowed with redaction, where a regulated field never reaches the model.
See the prior-authorization example →One enforcement point, backed by the whole platform
The gateway is less a new product than the runtime enforcement point that makes Keel's modules act on live traffic.
Enforcement proxy
MCP-aware and HTTP proxy in front of each context source.
Policy decision engine
Evaluates identity, delegation, purpose, data class, source and destination rules, with locally cached decisions.
Credential broker
Holds source credentials in KeelKey and mints per-request, scoped tokens.
Response filter
Classification, redaction and tokenization, provenance labels and token caps.
Flow-control tracker
Carries source and sensitivity labels through the session so later tool calls can be checked against them.
Revocation listener
Receives revoke events from the identity provider, the Governance kill switch and security tools.
Audit emitter
Writes one tamper-evident record per packet to Keel Intelligence.
Deployment
Hosted, in your VPC or as a sidecar next to agent runtimes. In-VPC deployments sync only policy and metadata to Keel, never content.
What it is
An authorization and enforcement layer for agent access to enterprise data. It answers: who may get this, for what, and what did they see?
What it is not
It does not index content, build a knowledge graph or rank results. It complements the search and data platforms you already run: they decide what is relevant, Keel decides who is allowed to get it.
Open standards, honest targets
The gateway sits on the agent's critical path, so policy evaluation is local and cached. Our design target is single-digit milliseconds of added latency for cached decisions, with fail-open or fail-closed set per source. These are design targets and are being validated with design partners, not measured results.
Pilot the Context Gateway on a real workflow.
Design partners put one agent workflow under delegated identity and policy, then test revocation and audit replay.