OpenViSTAI · Agents · Blockchain · Crypto
Submit a project
Menu
Agent Security & Sandboxing

Steward

Steward is self-hostable infrastructure that governs AI-agent provider credentials and wallet actions through encrypted storage, scoped grants, policy evaluation, approval workflows, credential proxying and signed audit evidence.

Explore the practical guide ↓

Independent OpenViST project profile, based on linked sources.

Steward — OpenViST project profile in Agent Security & Sandboxing.
OpenViST project illustration. See the linked sources for product details.
Understand the project

Practical overview

When it fits

Use Steward when an agent needs controlled access to provider credentials or wallets and the surrounding platform needs approval, authorization and audit layers that can be self-hosted.

Who it is for

  • Teams building autonomous-agent systems with wallet capabilities
  • Developers adding governed provider access to an existing agent runtime
  • Operators of multi-tenant platforms that need scoped authorization and audit evidence
  • Organizations implementing policy-controlled EVM transaction signing

Documented uses

  • Authorize agent access to configured provider capabilities
  • Gate wallet operations with policies, approvals and scoped grants
  • Proxy credentials without exposing raw provider keys to the agent runtime
  • Store wallet keys and credentials in encrypted form
  • Export evidence for offline audit verification
Before you choose

Requirements & limits

The repository describes Steward as open source under the MIT license and documents self-hosted Docker and embedded PGLite deployment modes. Operators bring their own runtime, cloud, identity provider and custody configuration.

  • Steward is an infrastructure layer, so teams need an existing agent runtime or application to connect to it.
  • Provider grants can be scoped by configured host, path, method, credential route, expiry and revocation state.
  • Human approval is documented for wallet workflows, while provider capabilities use exact-request approval and resume flows.
  • The primary EVM signing path has a stronger payload-bound, backend-bound and single-use authorization boundary; this does not cover every signing or proxy surface.
  • Audit bundles can be checked offline, but the verifier’s public key must be compared separately with an out-of-band trusted key or fingerprint.

Check current requirements in the official documentation. Source-based guidance does not mean OpenViST has run or independently tested this project.

Source-based practical guide

Connect an agent runtime to Steward’s authorization layer

Set up the documented SDK connection between an existing agent runtime and a self-hosted Steward instance.

Before you start

  • A self-hosted Steward instance
  • A TypeScript project
  • The @stwd/sdk package
  • A Steward tenant API key and tenant ID

Steps

  1. Install @stwd/sdk.

  2. Create a StewardClient with the self-hosted instance base URL, tenant API key and tenant ID.

  3. Use the client to create a named wallet for the agent.

  4. Pass a transaction request to Steward’s documented signTransaction method on the primary EVM signing path.

Expected outcome

The agent runtime is connected to Steward’s governed wallet API and can submit a transaction-signing request through its authorization layer.

Guide limitations

  • The supplied documentation does not provide the exact integration steps for every agent runtime.
  • The described execution authorization applies to the primary EVM transaction-signing path, not every signing or proxy surface.
Documentation 1 ↗
Source-based practical guide

Prepare a Docker self-hosting configuration

Prepare the documented environment for running Steward with Docker.

Before you start

  • The Steward repository
  • Docker deployment support
  • A copied .env file based on .env.example
  • Values for the secrets required by docker-compose.yml

Steps

  1. Clone the Steward repository and enter its directory.

  2. Copy .env.example to .env.

  3. Set the documented values for POSTGRES_PASSWORD, STEWARD_MASTER_PASSWORD, STEWARD_JWT_SECRET, STEWARD_EMAIL_CODE_SECRET, STEWARD_EXECUTION_AUTH_SECRET, STEWARD_KDF_SALT, STEWARD_AUDIT_HMAC_KEY and STEWARD_PROXY_REQUEST_SIGNING_SECRET.

  4. Continue with the repository’s deployment guide for the remaining deployment stages.

Expected outcome

The required environment configuration is prepared for the documented Docker deployment process.

Guide limitations

  • The supplied steps stop at environment preparation and do not establish that the service was started or configured successfully.
  • Operators must supply their own cloud, identity and custody configuration.
Documentation 1 ↗
Evidence and transparency

Sources & review

Official repository ↗
Source record details
Source availability
Active
Sources checked
3 October 2026
Original website title
Steward-Fi/steward · Official homepage title · retained in its source language
How we review sourcesSuggest a correction