Skip to main content
1Password and Autonomy collaborated on AI SRE agents that safely diagnose and autonomously fix problems in production infrastructure. This guide shows you how to deploy them to your infra. Agent swarms require execution environments with explicit identity and strict boundaries. Autonomy treats agent identity and isolation as first-class concerns. Each agent has a unique cryptographic identity, and every action is attributable by design. In this guide, we show how agents authenticate as themselves, request access dynamically, and receive credentials from 1Password that are scoped to intent, time-bound, and revocable.
OnCall Agent Swarm Visualization
When you go on-call, the agent requests read-only credentials from 1Password to monitor your infrastructure. A human approves access, and the agent starts watching for anomalies. When an incident occurs, a swarm of 150+ agents spins up: some inspect logs, others correlate metrics, others evaluate fixes. Each agent has its own cryptographic identity and uses the pre-approved read credentials to investigate.
After the swarm identifies the root cause, it requests write credentials for specific remediation actions:kill runaway queries, disable a feature flag. Each write action requires separate human approval. Once approved, the swarm autonomously remediates the problem. Here’s what that looks like in code. The investigation spawns a swarm of specialist agents across every region and service, then synthesizes their findings:
/dev/null/conceptual.py
The complete source code is available in Autonomy examples.

Try it

1

Sign up and install the autonomy command

Complete the steps to get started with Autonomy.
2

Get the example code

/dev/null/terminal.sh
This creates the following structure:
File Structure:
3

Configure 1Password Connect

Create secrets.yaml with your 1Password Connect token:
/dev/null/terminal.sh
secrets.yaml
Add your 1Password Connect credentials file. In the 1Password developer portal, create a Connect server and download the credentials file. Save it to:
/dev/null/path.txt
This file is gitignored and required for the 1Password Connect container to authenticate with your vault.
4

Deploy

/dev/null/terminal.sh
Once deployed, open your zone URL in a browser to access the incident response dashboard.
5

Trigger an incident

/dev/null/terminal.sh
Watch the dashboard as 150+ agents spawn and investigate the incident in real-time.

How it works

The application demonstrates a complete incident response workflow with secure credential handling. Monitor. A long-running Monitor starts when the app deploys and continuously watches for anomalies. In production, it would poll Prometheus, CloudWatch, or other metrics sources. For demos, anomalies are triggered via the /incidents endpoint.
images/main/main.py
Two-phase credential approval. The system uses a two-phase approach to balance investigation speed with security: Phase 1: READ credentials : When you go on-call, the agent requests read-only credentials to monitor infrastructure. These are approved once at activation and shared across all diagnostic agents when an incident occurs.
images/main/main.py
Phase 2: WRITE credentials : After diagnosis, if the swarm identifies remediation actions (kill queries, disable feature flags), it requests write credentials for each specific action. These require individual human approval.
images/main/main.py
Parallel diagnostic swarm. Agents are actors in the Autonomy runtime:they don’t block, allowing massive parallelism on a single machine. The investigation spawns specialized agents across regions and services:
Each specialist agent has specific diagnostic tools: Synthesis and remediation. After all diagnostic agents complete, a synthesis agent combines findings and identifies the root cause:
images/main/main.py
Each diagnostic agent runs with specialized instructions and tools:
images/main/main.py
After all diagnostic agents complete, a synthesis agent combines findings:
images/main/main.py
If the synthesis identifies remediation actions, the agent requests write credentials with individual human approval for each action. The dashboard includes a real-time D3.js force-directed graph that visualizes all agents as they spawn, investigate, and complete their work. POST /incidents : Trigger an incident investigation with 150+ diagnostic agents. Request:
/dev/null/request.json
Response:
/dev/null/response.json
GET /investigation/status : Get the current investigation status. Response:
/dev/null/response.json
POST /approve/ : Approve or deny credential access for an investigation. Request:
/dev/null/request.json
Response (streaming): Events indicating credential retrieval, agent spawning, and diagnosis progress. Additional endpoints for visualization (/graph), history (/investigation/history), and health checks (/health) are available in the source code.

Customize for your infrastructure

The example uses mock tools and manual triggers for demonstration. To adapt for your infrastructure:
  • Connect your monitoring : Replace the manual /incidents trigger with your observability stack. The Monitor._monitor_loop() can poll Prometheus, CloudWatch, or Datadog for anomalies.
  • Implement real diagnostics : Replace mock tool functions with actual infrastructure queries. For example, query_db_connections becomes a real PostgreSQL connection pool query, get_cloudwatch_metrics uses the AWS SDK.
  • Map your infrastructure : Update REGIONS and SERVICES to match your actual deployment topology. Add specialists for your stack (Redis, Kafka, etc.).
  • Configure 1Password : Set up vaults with your infrastructure credentials. The read/write separation ensures diagnostic queries use read-only access while remediation requires explicit approval.

Learn more

Models

Available models for agents.

Agents

Build agents with custom instructions and tools.

Tools

Give agents the ability to take actions.

Programming Interfaces

Create APIs for Autonomy applications.