Secure Agent Runtime Architecture
Architecture at a Glance
Andyur creates a governed execution boundary around every AI agent run. The platform separates deterministic control-plane functions from agent execution, treats the agent workload as untrusted, and mediates access to models, tools, data and enterprise services through a trusted runtime.
Admission resolves the approved agent artifact, identity, model/tool grants, runtime policy and compute constraints before a run is materialized.
Each run receives its own runtime boundary, credentials, network policy and execution identity.
The trusted runtime brokers model, tool and enterprise API access so credentials do not need to live in the agent.
Workload identity, run identity and enterprise authorization combine to make downstream actions traceable to a specific execution.
1. Control Plane and Agent Data Plane
The Andyur control plane is intentionally deterministic. It owns admission, registry resolution, policy, lifecycle, identity expectations and run state. Model-driven behavior remains inside agent runs rather than being embedded in the coordinator.
| Control plane | Per-run data plane |
|---|---|
| Agent registry and artifact governance | Trusted Andyur proxy / broker |
| Policy and admission | Untrusted agent workload |
| User and workload identity checks | Model and tool invocations |
| Run scheduling and lifecycle | Scoped runtime credentials |
| Audit, state and orchestration metadata | Execution-specific telemetry |
2. Kubernetes Runtime Architecture
Andyur deliberately separates the trusted runtime from the untrusted agent into different pods. That decision allows Kubernetes NetworkPolicy to give the runtime broader, explicitly approved connectivity without giving the same network authority to the agent.
Each admitted run is materialized as a bounded set of Kubernetes resources such as service accounts, per-run secrets, a proxy service, default-deny policies and the workload pods. Runtime resources are derived from the admitted run rather than selected by the agent image.
3. Network Containment
The run network is designed around default deny. The agent receives only the connectivity required to speak to its own Andyur runtime. The trusted runtime receives a separately governed set of outbound destinations for the specific model, tool, control-plane and telemetry services that the run is authorized to use.
No general DNS or cluster reachability for the agent
Removing unnecessary resolver and cluster reachability reduces both discovery and exfiltration paths. Service resolution required by the trusted runtime remains outside the agent's authority.
Fail-closed containment activation
Dynamic network policy can take time to become effective after a pod is created. Andyur uses a containment barrier so the untrusted workload does not begin until isolation is observed as active. If the required boundary cannot be established, the run is refused rather than started with broader connectivity.
4. Identity and Delegated Authority
Andyur separates three questions that are often collapsed into a single bearer credential: who is the workload, which run is acting, and what authority has been delegated.
| Layer | Purpose |
|---|---|
| Workload identity | SPIFFE/SPIRE establishes cryptographic identity for trusted platform and run-side workloads. |
| Run identity | Agent, run and workflow context binds requests to a specific execution rather than a generic service role. |
| Delegated authority | Enterprise authorization constrains audience, scope and permitted downstream actions. |
5. Credential Isolation
Traditional agent deployments often place provider keys, OAuth tokens or service credentials directly in the agent process. Andyur's runtime model instead keeps downstream credentials in trusted infrastructure and applies them only when an authorized operation is performed.
| Credential-control property | Security effect |
|---|---|
| Reduced secret exposure | A compromised model context has fewer downstream credentials available to steal. |
| Scoped downstream actions | The runtime can apply credentials appropriate to the approved audience and operation. |
| Independent revocation | Authority can be removed without changing the agent image. |
| Auditable mediation | Model and tool actions pass through an enforcement point that can emit policy and trace evidence. |
6. Governed Agent Supply Chain
Execution begins from governed artifacts, not mutable image tags or ad hoc runtime configuration. An agent package and manifest are resolved through the registry and admission layers, then bound to an immutable run specification.
The resulting run specification can include the immutable workload artifact, agent identity, model and tool grants, resource bounds, network destinations, run lifetime and isolation requirements. This makes the compute layer an implementation of an already-approved contract rather than the place where policy is invented.
7. Bring Your Own Agent
Andyur is designed to govern existing agents and containers rather than requiring every workload to be rewritten around a proprietary SDK. The runtime contract provides the agent with only the approved interfaces and configuration needed for the run, while infrastructure-specific identity, credentials and network policy remain outside the agent.
8. Compute and Run Lifecycle
Andyur keeps execution semantics separate from Kubernetes objects. A run has a stable identity and execution generation; the run controller turns that admitted intent into exactly one active runtime and observes it through completion.
Resource requests and limits can be resolved independently for the trusted runtime and agent workload. This supports predictable CPU, memory and ephemeral-storage bounds while allowing enterprises to map higher-risk or GPU workloads to different node pools and runtime classes.
9. Enterprise Production Topology
A production deployment scales the control plane independently from agent compute. Server replicas remain stateless over shared durable state and object storage; run controllers materialize agent workloads into appropriate compute pools; SPIFFE/SPIRE and telemetry span both planes.
Compute segmentation
| Compute class | Example use |
|---|---|
| Standard CPU | Internal and lower-risk agents |
| High-isolation | Third-party/BYOA workloads using stronger sandbox runtimes |
| High-memory | Large context processing, data transformation and retrieval workloads |
| GPU | Local inference, vision and accelerated agent workloads |
| Tenant-dedicated | Deployments requiring stronger infrastructure tenancy boundaries |
10. Controlled Egress
Cluster-local policy can precisely constrain pod and namespace destinations. Public SaaS and enterprise endpoints may require an egress gateway or an FQDN-aware network control so outbound policy remains stable even when external service IPs change.
11. Composable Infrastructure
Andyur's architecture separates orchestration, run execution and compute so enterprises can evolve infrastructure without changing the agent security contract.
| Boundary | Examples |
|---|---|
| Orchestration provider | Local execution, Temporal, enterprise durable workflow systems |
| Compute provider | Kubernetes, Docker and future cloud/managed compute backends |
| Isolation technology | Containers, sandboxed runtimes, microVM-based isolation |
| Identity | SPIFFE/SPIRE and enterprise workload-identity integrations |
| Authorization | Enterprise identity provider, policy decision point and authorization server |
| Secrets | Enterprise vault and cloud-native secret systems |
Specific integrations and deployment modes depend on the selected Andyur release and enterprise environment.
12. What the Architecture Means for Enterprise Security
| Architecture mechanism | Enterprise outcome |
|---|---|
| Separate agent and trusted runtime pods | A compromised agent does not automatically inherit the runtime's downstream network authority. |
| Default-deny networking | Agents cannot freely roam the cluster or enterprise network. |
| Credential mediation | Provider and tool secrets do not need to be resident in the agent process. |
| Per-run workload identity | Actions can be associated with a specific execution rather than a generic shared service identity. |
| Immutable governed artifacts | Approved code and configuration cannot silently drift at launch time. |
| Fail-closed containment barrier | The workload is not started until required network isolation is active. |
| Resource and compute policy | Runaway or high-risk agents can be bounded and placed on appropriate infrastructure. |
| Mediated egress and telemetry | Model/tool actions pass through enforceable, observable runtime paths. |
Architecture Statement
This architecture allows enterprises to bring agent frameworks and workloads into a common runtime security model while preserving their existing identity, authorization, networking, observability and compute infrastructure.
This document describes Andyur's external architecture model. Exact capabilities, integrations and deployment topology can vary by release and customer environment. Security-sensitive deployments should validate the selected configuration and controls against their own threat model.