How FirstOps Fits Into Your Stack#

FirstOps adds a security and governance layer to your existing AI agent setup. Nothing changes about how you build agents — FirstOps governs what they can do at runtime.

What runs where#

On your machine#

The daemon is a lightweight background process started by fo setup. It does three things:

Proxies MCP traffic — Your agent's MCP tool calls route through the daemon instead of going directly to upstream servers. The daemon signs each request with a DPoP proof and forwards it to FirstOps, where policies are evaluated and credentials are injected.
Intercepts agent actions via hooks — For coding agents (Claude Code, Cursor), the daemon hooks into the agent's lifecycle. Before the agent runs a shell command, writes a file, or installs a package, the hook fires and the daemon evaluates the action against your policies.
Scans for connections — The daemon periodically scans MCP configurations across your installed AI tools, discovers new connections, and reports them to the dashboard.

The daemon runs entirely on your machine. It communicates with FirstOps Cloud over HTTPS.

Your agent configs change minimally. When you fix an unmonitored connection, FirstOps rewrites the MCP server URL to point at the local daemon instead of the upstream server directly. That's it — no SDK changes, no code changes. Your agent doesn't know FirstOps exists.

In FirstOps Cloud#

FirstOps Cloud is where policy evaluation, credential storage, and audit logging happen. When you fix a connection, upstream credentials (API keys, OAuth tokens) are removed from your local config and stored server-side in FirstOps. From that point on, your machine only holds your FirstOps identity — never the upstream secrets. FirstOps injects them into requests right before forwarding to the upstream service.

From your perspective, FirstOps Cloud is a single endpoint.

Your upstream tools#

Nothing changes on the upstream side. Notion, GitHub, Slack — they receive properly authenticated requests with valid credentials. The request payload and authentication are identical to what your agent would have sent directly.

Two enforcement paths#

Every agent action takes one of two paths through FirstOps:

Path 1: MCP tool calls#

Agent → Daemon (local proxy) → FirstOps Cloud → Upstream Tool

The agent calls an MCP tool. The daemon proxies the request to FirstOps, which authenticates it (DPoP), evaluates policies, injects the upstream credential, and forwards the request. The response flows back through the same path, with policies evaluated on the return trip too.

This path handles credential brokering — your agent never sees raw API keys or OAuth tokens.

Path 2: Shell, files, and code (client hooks)#

Agent → Hook fires → Daemon → Policy decision → Allow / Deny / Ask

The agent attempts a non-MCP action (shell command, file write, package install). The agent's hook system fires before execution. The daemon evaluates the action and returns a decision. If denied, the agent receives a reason. If flagged, the action proceeds but is recorded for review.

This path handles actions the MCP gateway never sees — everything an agent does outside of tool calls.

The same policy engine — one set of rules governs all agent behavior
The same audit trail — tool calls and shell commands appear in the same log
The same identity — the principal (human or agent) is resolved the same way

What doesn't change#

Your agent code — no SDK required for coding agents, no code changes
Your upstream tools — they don't know FirstOps exists
Your agent's capabilities — FirstOps governs, it doesn't limit what tools are available (unless your policies say so)
Your development flow — fo setup once, then everything works in the background

Enforcement — How policies are evaluated across both channels
Connections — How connections are discovered and monitored
Identity & Auth — How DPoP authentication works
Principals — The identity model for humans and agents