Skip to content
Agent Trust Cloud

Architecture

Separate the management plane from the enforcement plane

The platform should separate the management/control plane from enforcement/data-plane components. The cloud control plane manages inventory, policy, analytics and administration. Customer-side or regional gateways enforce sensitive actions close to workloads and can be deployed in modes that minimize data leaving the customer boundary.

Priority
P0
Phase
Foundation
Primary owner
CTO / Platform
Status
Blueprint

Components

Five layers, versioned schemas, no shared fate

Gateways stay stateless and horizontally scalable, secrets live in a dedicated layer, and telemetry moves over queues so an analytics outage never blocks a safe runtime decision.

Control plane

Manage inventory, policy and analytics.

  • Tenants & users
  • Agent registry
  • Policy authoring
  • Risk analytics
  • Reporting
  • Billing
  • Configuration

Runtime gateway

Enforce close to the workload.

  • Request interception
  • Identity verification
  • Policy evaluation
  • Redaction
  • Approval orchestration
  • Forwarding

Telemetry pipeline

Ingest without ever blocking a decision.

  • Append-only ingestion
  • Normalization
  • Enrichment
  • Searchable storage

Connector fabric

Coexist with the existing stack.

  • AI platforms
  • Clouds
  • Identity providers
  • SaaS
  • SIEM
  • MCP
  • APIs

Evidence store

Tamper-evident records for audit and investigation.

  • Immutable records
  • Policy versions
  • Approvals
  • Incident links

Reference flow

  1. Agent

  2. Agent Trust Gateway

  3. Identity + policy + risk decision

  4. Protected tool / API

  5. Event / evidence pipeline

Implementation decisions

  • Use stateless horizontally scalable gateways where possible; keep secrets in a dedicated secrets layer.
  • Define versioned schemas for agents, identities, tools, actions, resources, policies, decisions and evidence.
  • Use queues/streams for telemetry so analytics outages never block safe runtime decisions.
  • Design regional isolation and customer-managed deployment options early enough to avoid architectural rework.

Definition of done

  • A request can be evaluated locally when cloud analytics is degraded.
  • All components emit correlated trace IDs.
  • A tenant can export inventory, policies and events through APIs.

REFERENCE FLOW

Agent → Agent Trust Gateway → identity + policy + risk decision → protected tool/API → event/evidence pipeline.

Zero trust

Security Architecture & Zero Trust

Agent Trust Cloud should implement zero-trust principles internally and expose them as customer controls. NIST SP 800-207 emphasizes resource-focused protection and explicit authentication and authorization rather than implicit trust based on network location. That maps naturally to agents because agents are mobile software principals that can operate across clouds, SaaS and tool boundaries.

What we build

  • Mutual authentication between gateways, connectors and control-plane services.
  • Short-lived credentials and workload identities instead of long-lived static keys.
  • Fine-grained service authorization enforced at every sensitive internal API.
  • Strict separation of tenant data, administrative operations and production secrets.
  • Continuous vulnerability management, dependency scanning, secrets scanning and threat modeling.

Internal security zones

  • Create internal security zones: public edge, control plane, telemetry, evidence, secrets and administration.
  • Adopt deny-by-default service permissions; authorize service-to-service calls by identity.
  • Encrypt data in transit and at rest, with envelope encryption for high-sensitivity stores.
  • Document the shared-responsibility model for SaaS vs. customer-managed gateway deployments.

STANDARDS ANCHOR

Use NIST Zero Trust Architecture as a design reference; adapt it to agent principals, delegated authority and tool-level decisions.

Data model

Core Data Model & Event Schema

The data model is a strategic asset. If Agent Trust Cloud normalizes agent identity, delegation, tools, resources and actions across vendors, every downstream module—policy, risk, audit, FinOps and incident response—gets stronger. Avoid vendor-specific event models leaking into the core domain.

Canonical objects

  • Principal objects: human, workload, agent, service account, application and external actor.
  • Agent objects: owner, purpose, provider, model, framework, environment, trust state, capabilities and lifecycle state.
  • Authority graph: who delegated to whom, what scope, when, through which credential and for what purpose.
  • Action events: requested tool, operation, target resource, parameters fingerprint, decision, approval, outcome and cost.
  • Evidence objects: logs, prompts/hashes, policy versions, approvals, external alerts and incident links.

Schema rules

  • Use globally unique immutable IDs; store display names separately.
  • Version policy, identity and agent configuration so past decisions can be reconstructed.
  • Normalize resource URIs and action verbs into a canonical vocabulary while preserving raw vendor fields.
  • Design PII/secret classification metadata into schemas rather than adding it later.

DATA MOAT

The normalized agent-authority-action graph becomes the foundation for cross-vendor security intelligence.

Explore the capabilitiesDeveloper platform