Anchorage

Anchorage adds enforceable guardrails, durable approvals, and physically isolated long-running execution to Mastra on Cloudflare.

Try the live demo · Read the docs · Browse the API reference · Get support

Why Anchorage

Mastra supplies the agent and workflow runtime. Anchorage adds the controls that become necessary when those agents can change real systems or remain active beyond one request:

• Every side-effecting connector declares its permissions, then enforces egress, approval, idempotency, dry-run, rate-limit, and isolation policy at the tool boundary.
• Runs suspend without keeping compute alive, survive Worker and Durable Object restarts, and resume from authoritative D1 snapshots.
• Approval grants are derived from stored decisions and bound to the exact suspension. A client cannot mint a capability by forging a resume body.
• Each organization runs in its own Worker, D1 database, and Durable Object namespaces. A strict deployment sentinel and internal caller credential fail closed on database or object-binding drift.
• Structured audit events can feed metrics, Cloudflare Queues, and a SIEM.

Use Anchorage when you already use Mastra and Cloudflare, and your agents perform writes, need human review, run for a long time, or accept signals. Deploy one Flowsafe data plane per organization.

Anchorage is not a model provider, identity provider, hosted SaaS, generic process sandbox, or complete network perimeter. You provide authentication and deployment policy. Socket-level egress control still belongs in your infrastructure.

Choose a package

Package	Install when you need	Main surfaces
@proofoftech/breakwater	Guardrails around Mastra agents and tools	Guarded agent handles, policy processors, RBAC, audit and metrics, connector SDK, Claude Code and Codex CLI connectors
@proofoftech/flowsafe	Durable execution and human approval on Cloudflare	Guarded agent catalog/host, Durable Object runner, approval API and React UI, signals, goals, schedules, background tasks, provider subscriptions, R2 artifacts, SIEM export
@proofoftech/fleet-control	Provisioning physically isolated deployments from a trusted control plane, never from a Worker that serves tenant requests	Workers for Platforms and staged Wrangler backends, fenced fleet state, release promotion and rollback, bidirectional inventory, platform dispatch/outbound/audit Workers

Fleet control requires Node 22.22.0 or later. Flowsafe requires Node 22 or later. Breakwater requires Node 22.3 or later for its built-in Agent CLI executor. All three packages are ESM-only. Breakwater and Flowsafe require @mastra/core 1.50.0. React 18 or 19 is needed only for the optional Flowsafe approval UI. Hosts that run flowsafe-provision or the Fleet Control Wrangler backend must provide Wrangler >=4.118 <5; Wrangler is not a Flowsafe peer dependency.

Start with breakwater

npm install @mastra/core@1.50.0 @proofoftech/breakwater

Create a guarded agent and pass the authenticated actor through Mastra's RequestContext:

import { RequestContext } from '@mastra/core/request-context';
import {
  ACTOR_CONTEXT_KEY,
  AuditLogger,
  createGuardedAgent,
  denyPatterns,
} from '@proofoftech/breakwater';

const audit = new AuditLogger({
  sink: async (event) => {
    console.log(JSON.stringify(event));
  },
});

const model = process.env.MASTRA_MODEL_ID;
if (!model) throw new Error('MASTRA_MODEL_ID is required');

const agent = createGuardedAgent({
  id: 'release-agent',
  name: 'Release agent',
  instructions: 'Prepare releases without exposing secrets.',
  model,
  allowedRoles: ['operator', 'admin'],
  policies: [denyPatterns(['private key', 'ignore previous instructions'])],
  audit,
  maxSteps: 8,
  toolChoice: 'auto',
});

const requestContext = new RequestContext();
requestContext.set(ACTOR_CONTEXT_KEY, {
  id: 'operator-42',
  role: 'operator',
});

const result = await agent.generate('Prepare the release notes', {
  requestContext,
});

For writes, wrap the Mastra tool with createConnector(). The manifest is enforced on direct calls, workflow calls, and agent calls:

import {
  createConnector,
  InMemoryIdempotencyStore,
  InMemoryRateLimitStore,
} from '@proofoftech/breakwater/connector-sdk';
import { z } from 'zod';

export const publishRelease = createConnector({
  id: 'releases.publish',
  description: 'Publish one release',
  inputSchema: z.object({ releaseId: z.string() }),
  outputSchema: z.object({ published: z.boolean() }),
  permissions: {
    sideEffect: 'write',
    egress: ['api.example.com'],
    requiresApproval: true,
    idempotencyKey: true,
    dryRun: true,
    rateLimit: '10/hour',
  },
  policies: {
    idempotencyStore: new InMemoryIdempotencyStore(),
    idempotencyKeyMigration: 'legacy-writers-drained',
    rateLimitStore: new InMemoryRateLimitStore(),
  },
  execute: async ({ releaseId }, _context, runtime) => {
    const response = await runtime.fetch(
      `https://api.example.com/releases/${releaseId}`,
      { method: 'POST' },
    );
    return { published: response.ok };
  },
  dryRunExecute: async () => ({ published: false }),
});

The in-memory stores make this definition runnable in one process. The migration acknowledgement is safe here because the example constructs a fresh store that no legacy writer can reach; an upgraded shared store requires the documented drain and inventory first. Use the D1 stores when replay or rate limits must span Workers or Durable Objects. The connector authoring guide explains every permission, required store, and accepted limit: packages/breakwater/CONNECTORS.md.

Add durable approvals

npm install @mastra/core@1.50.0 @proofoftech/breakwater @proofoftech/flowsafe

Start from the copy-ready baseline Worker in packages/flowsafe/deploy/. It wires one Durable Object per run, D1 snapshots and approvals, authenticated run routes, server-derived connector grants, live-streaming opt-in, SLA sweep, retention, audit export, and a sample gated workflow.

For a long-running agent host with signals, goals, schedules, provider subscriptions, and background tasks, use the private workspace starter in packages/agent-starter/. The starter composes only published package entry points, so it also serves as a consumer-level compatibility test.

The full path from install to first approval is in docs/getting-started.md.

Feature map

Guardrails and connectors

• Mastra input and output processors with answer, reasoning, and structured-object channels
• Streaming deny-pattern inspection with optional zero-leak hold-back
• PII and secret detection using structured patterns, entropy checks, Luhn validation, allowlists, and streaming windows
• Pluggable asynchronous classifier with fail-closed timeout behavior
• Agent-boundary RBAC and workflow-scoped host authorization
• Permission manifests for side effects, declared egress, approval, idempotency, dry-run, background eligibility, and fixed-window rate limits
• Per-hop egress enforcement for calls made through the injected connector runtime, including redirect checks and cross-origin credential stripping
• In-memory and D1-backed idempotency and rate-limit stores
• Workflow and opaque isolation-scope evaluators
• Approval-gated Claude Code and Codex connectors with argv separation, bounded execution, dry-run previews, and safe diagnostics
• Structured audit sinks, metrics adapters, and sink fan-out

Durable approvals and execution

• D1-backed Mastra workflow snapshots with a one-run-per-Durable-Object topology
• CAS-guarded approval claim, decision, delegation, batch decision, SLA escalation, and notification
• Separation of duties across repeated gates and exact suspension-bound grant derivation
• Styling-library-agnostic React 18/19 dashboard, headless hook, polling fallback, optimistic decisions, live WebSocket merge, presence, and injected UI slots
• Deployment-wide live approval and per-run streams using short-lived HMAC addressing tickets
• R2 artifact storage, lifecycle pairing, terminal-run retention, and thread retention
• Cloudflare Queues to SIEM NDJSON export

Long-running agents

The following surfaces are supported and opt-in: they are tested and covered by package compatibility guarantees, but the host must explicitly wire the required routes, bindings, storage domains, or alarm-driven duties.

• Server-owned guarded-agent catalog with authenticated list, start, status, and NDJSON observation routes
• Approval-only durable agent resume that restores the original authorized principal
• Runtime-driven Mastra durable agents with restart-safe approval resume
• Server-minted thread ids and validated host-owned resource keys with D1-backed memory
• Thread signals, messages, state, notifications, idle wake, and a DOM-free client
• Durable objectives and bounded goal updates
• Workflow and agent schedules with CAS fire claims and reserved-context protection
• Deployment-scoped background task execution and cleanup
• Alarm-driven signal providers, human-managed subscriptions, verified webhooks, and GitHub reference integration

See docs/durable-agents.md for the wiring and lifecycle.

Demo

The public showcase runs the open-source stack in one shared demo organization. It includes six server-side workflows and seven deterministic guardrail scenarios covering personally identifiable information (PII), secrets, prompt injection, role-based access control (RBAC), egress, workflow isolation, and opaque isolation scopes. External side effects are simulated unless the corresponding binding is configured. Approval, grant, audit, deployment identity, and suspend/resume paths are real.

Run it locally:

corepack enable
pnpm install --frozen-lockfile
pnpm build
pnpm dev

Documentation

• Documentation index
• Getting started
• Connector SDK contract
• Agent CLI connectors
• Approval system
• Durable agents
• Deployment reference
• Security threat model
• Operations runbook
• Generated API reference

Development

corepack enable
pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm test
pnpm build
pnpm docs:check
pnpm docs:api
pnpm --filter @proofoftech/flowsafe spike:verify

The deterministic workerd spike proves suspension, restart, resume, forged-resume denial, deployment isolation, live streaming, durable agent recovery, schedules, signals, goals, provider delivery, and background tasks without an external model. The separate spike:verify:llm gate is optional and requires provider credentials.

Support, security, and contributing

Read SUPPORT.md for help, SECURITY.md for private vulnerability reporting, and CONTRIBUTING.md before opening a pull request. Contributions are accepted under Apache-2.0 without a CLA or DCO requirement.

License

Apache-2.0. See LICENSE.