Skip to main content

​
Architecture

Steward provides governed paths for configured agent provider calls and wallet operations. Only requests routed through supported Steward integrations receive these checks and audit events. Arbitrary agent network egress remains outside the boundary.

​
Three Pillars

Wallet Vault

Encrypted key storage for supported signing paths. Governed routes apply policy before signing.

Secret Vault

Encrypted credential storage with injection on configured proxy routes.

Policy Engine

Declarative policy evaluation on enrolled, governed actions. Default deny.

​
High-Level Flow

​
Request Flow: API Proxy

When an agent makes an API call (e.g., to OpenAI):

​
Request Flow: Wallet Signing

When an agent needs to sign a transaction:

​
Deployment Modes

Steward currently supports two database modes:
  • PostgreSQL mode — API and proxy processes connect to PostgreSQL using DATABASE_URL. This is what Docker Compose and durable self-hosted deployments use.
  • Embedded/PGLite mode — bun run start:local runs the API against PGLite, persisted at ~/.steward/data unless STEWARD_PGLITE_MEMORY=true is set. This is intended for local development, desktop sidecars, and tests.

​
Deployment Topology

Agent containers can be firewalled to only reach the Steward proxy. Even if fully compromised, an agent cannot exfiltrate data to arbitrary endpoints.

​
Multi-Tenant Isolation

Steward is multi-tenant by design:
  • Tenants are always scoped by authenticated service-layer predicates and ownership constraints such as composite foreign keys. Production PostgreSQL adds database RLS: operators provision distinct application, platform, migration, and bootstrap-owner roles, activate and force the inventoried policies, and configure STEWARD_APP_DATABASE_ROLE. Bun startup and /ready, plus Worker cold start, compare the connected non-owner, NOBYPASSRLS role and the live relation/policy catalog to the generated manifest and fail closed on drift. Trusted request middleware binds steward.tenant_id transaction-locally on one checked-out connection. Embedded/local PGLite does not provide the production RLS role/catalog boundary and relies on service-layer predicates and ownership constraints. See PostgreSQL tenant RLS rollout.
  • Agents authenticate with JWTs scoped to their tenant and agent ID
  • Secrets and signing keys use domain-separated scrypt roots. Each record gets a random salt, and AES-GCM authenticates its tenant/agent/name/version context as AAD. There is no stored or independently rotatable per-tenant encryption-key layer. See Secret Vault and the root secret rotation runbook.
  • Policies are evaluated per-agent within their tenant context

​
Tech Stack