Actiondb.write
Agentsupport-bot
Policypolicy.governance.2.1
DecisionBLOCKED
Architecture
How the AI Agent Gateway is deployed.
All agent actions pass through a control layer that enforces policy before execution inside your infrastructure.
§ 1.0
System boundary.
The control layer sits between agents and enterprise systems and runs inside the customer perimeter. The diagram below describes the deployment at the block-diagram level; topology and internal naming are deliberately omitted.
The control layer is deployed as an enforcement boundary between agents and downstream systems inside your infrastructure.
Inside your infrastructure
The control plane runs in your VPC, your data centre, or your air-gapped environment. Nothing in the diagram resides outside the customer perimeter.
Between agents and enterprise systems
No agent reaches a downstream surface directly. Every action from agent to system is enforced by the control layer.
Every agent request
Authorization happens on every agent request -- not at the perimeter, not at the prompt, not after the fact.
§ 2.0
Action enforcement lifecycle.
Every agent action follows the same five-step sequence. The shape of the lifecycle does not change with the agent, the framework, or the downstream system.
Action
agent forms a proposed action
↓
Decide
decision
block·allow·redact·approve
↓
Conform
inputs redacted, masked, transformed, or refused
↓
Execute
downstream system receives a policy conformed action
↓
Record
decision record written to customer controlled storage
01 — Action
An agent forms a proposed action. Identity, user context, scope, and target surface are bound before the action can proceed.
02 — Decide
A deterministic policy decision is made for this action under the bound policy version.
03 — Conform
Inputs may be redacted, masked, transformed, or refused before dispatch.
04 — Execute
The downstream system receives only an authorised, policy conformed action.
05 — Record
A structured decision record is written to customer controlled storage.
§ 3.0
Control points.
Three control points along every action. The same three points apply uniformly across frameworks, models, and downstream systems.
Phase 01
Pre
Operates on
Intent — the action and its arguments before any downstream contact.
Outcome
Block, redact inputs, or proceed under the bound policy.
Phase 02
During
Operates on
Execution — spend ceilings, concurrency ceilings, approval state, and execution conditions.
Outcome
Pause for approval, reject, refuse, or proceed under policy.
Phase 03
Post
Operates on
The response from the downstream system before it returns to the agent.
Outcome
Redact, mask, refuse, or return — and write the decision record either way.
§ 4.0
Identity and access model.
Permissions are scoped at the action layer. An agent does not "have access" to a system — it has the right to invoke a specific action under a specific policy, on behalf of a specific user or service.
User-scoped access
Each action is attributed to the human user the agent is acting on behalf of. The agent cannot exceed the user's own permissions on the underlying system.
Service and team boundaries
Policies bind to teams, services, and use cases. A sales-team agent cannot reach engineering surfaces; a support service cannot mutate billing records.
Tool and MCP access control
Tool access is enforced per invocation. A virtual MCP server exposes only the tools an agent is permitted to call, with capability-scoped responses.
Human approval gates
Designated actions — financial transfers, irreversible writes, externally-visible communications — route to a human approver before execution. Approval state is part of the decision record.
Least-privilege enforcement
Default deny. An agent has no permission to invoke any action until that action is explicitly allow-listed under a policy. New tools are unreachable by default.
§ 5.0
Policy evaluation.
A policy is the standing answer the layer applies to every action under its scope. Policies are referenced by a stable, structured name. The reference is shown below; the implementation is intentionally not.
Evaluated per action
Policy is not evaluated once per session. It is re-evaluated for every action — the same agent under different conditions can receive different decisions.
Versioned and auditable
Every policy carries a version. Older actions remain attributable to the policy version under which they were evaluated.
Applied before execution
The decision is reached before the action reaches a downstream system. By the time execution begins, the boundary has already been enforced.
Anatomy of a policy reference
policy
.
governance
.
2.1
prefix
Constant
policy — declares this is a policy reference, not an action or an identifier.
domain
The policy's scope —
governance, finance, pii, engineering. Bound to teams and use cases.
version
Semantic version. Decisions are attributed to the version that evaluated the action.
§ 6.0
Data boundary.
Data does not leave your infrastructure unless explicitly permitted by policy.
What stays inside
Prompts, model responses, tool inputs and outputs, agent state, and decision records remain inside the customer perimeter.
What is logged
A structured decision record per action — agent, user, action, policy, decision, and the inputs and outputs that were either dispatched or returned. Logs are written to customer-controlled storage.
What is redacted
PII detected in inputs is redacted before dispatch. PII detected in outputs is redacted before the agent receives the response. Categories are configurable.
How outputs are controlled
Responses pass through the post-execution checkpoint before the agent sees them. Output policies can mask credentials, strip confidential fields, or refuse the response entirely.
Zero data egress
The control plane runs as customer-resident infrastructure. Outbound connections are limited to the surfaces the customer has explicitly allow-listed. AI Agent Gateway itself receives no telemetry containing customer data.
§ 7.0
Decision record · structured · illustrative
Decision records.
Every action becomes a structured decision record. The same record format is used everywhere on the system — platform, security posture, and customer controlled storage.
7.1
Every action is evaluated — against a deterministic policy decision, not a model-based guess.
7.2
Every decision is recorded — written before any side effect leaves the layer.
7.3
Full chain of custody — agent, user, action, policy, decision, all attributable, all in customer storage.
§ 8.0
What is not exposed.
A reference architecture is read by reviewers, by procurement, and — if the page is careless — by adversaries. The following are deliberately omitted from this page. Trust is built by acknowledging the boundary, not by hiding that there is one.
Internal system topology
Service names, process boundaries, queue topologies, storage layers, and inter-service protocols are not published. The diagram in §1.0 stops at the block-diagram level by design.
Policy implementation details
The policy reference (
policy.<domain>.<version>) is shown. The policy DSL, evaluation engine, rule syntax, and configuration files are not published on this site.Infrastructure layout
Customer-specific deployment topology, network segmentation, and host-level layout are not described publicly. They are part of the security review under NDA.
What is shared on review
The full reference architecture, control mappings to SOC 2 / HIPAA / GDPR, threat model, and customer-specific deployment plans are shared during the security review process.
§ 9.0 — Continue
Bring your deployment model.
The reference architecture is the public read. The next step depends on whether you are leading the review, briefing the executive sponsor, or matching the architecture to your existing security posture.
For the CISO
Talk to security
A direct conversation with the engineer who built the control layer. Bring your threat model. We will walk through the architecture, the boundaries, and the deployment options against your stack.
For the security architect
See the security posture
The full security posture: deployment boundary, identity model, enforcement checkpoints, decision records, data handling, and compliance posture — at the abstraction level a reviewer needs to scope a security review.
For the VP Platform / sponsor
Read the executive guide
Why agents created a new control problem, what the AI Agent Gateway is, and how to bring it through procurement. One PDF, written for the buyer.