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.
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 |
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.
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.
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.
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.
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. |
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. |
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.
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.
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.
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 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 |
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.
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.
| 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. |
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.