Documentation

Human-Delegated Agents#

A human-delegated agent acts on behalf of a specific user. The user's identity is the primary principal — the agent inherits permissions from the user's access group.

When to use this model#

  • Developer tools (Cursor, Claude Code) where the agent acts as the user
  • Assistants that need the same access as their human operator
  • Interactive workflows where a human is in the loop

How it works#

  1. The human authenticates with FirstOps (fo auth login)
  2. The CLI starts a daemon with the human's DPoP credentials
  3. AI tools connect to upstream services through the FirstOps gateway
  4. Every request is attributed to the human principal
  5. The human's access group policies are applied



  
    
  
  
    
  







  
  fo auth login


  
  Generate DPoP key pair


  
  Register public key


  
  Request (with DPoP proof)


  
  Verify proof → identify user


  
  Evaluate policies


  
  Forward (inject credentials)


  
  Response


  
  Response


  
  User


  
  CLI


  
  Agent


  
  Gateway


  
  Upstream

Setup#

1. Authenticate#

fo auth login

2. Run setup#

fo setup

This starts the daemon and scans for MCP connections.

3. Fix connections#

fo discover fix --all

All discovered connections now route through the gateway under your identity.

What's governed#

Human-delegated agents are governed through both enforcement channels:

MCP tool calls (gateway)#

Every MCP tool call is routed through the FirstOps gateway. Policies are evaluated, credentials are injected, and the interaction is logged — all under your identity.

Shell, files, and code (client hooks)#

Coding agents like Claude Code and Cursor also execute shell commands, write files, and install packages. FirstOps intercepts these actions through the agent's native hook system.

The daemon installs hooks automatically when it detects a supported coding agent. Before the agent runs a shell command or writes to a sensitive file, the action is evaluated against your access group's policies.

Examples of what hooks catch:

  • Blocking rm -rf / or other dangerous shell commands
  • Preventing writes to .env, SSH keys, or CI configs
  • Flagging reads of credential files for audit review
  • Prompting the user before high-risk actions

Audit trail#

Every action — both MCP tool calls and hook-intercepted actions — shows:

  • Principal: Your user identity
  • Source: The AI tool that made the request
  • Action type: Tool call, shell command, file write, etc.
  • Decision: Allow / Deny / Flag / Modify
  • Timestamp: When it happened

Admins can view your activity in the audit dashboard. You can view your own activity in the user view.

Limitations#

  • The agent cannot exceed the human's permissions
  • If the human's credentials are revoked or expire without refresh, the agent loses access
  • Credential rotation requires re-authentication (fo auth login)
  • Client hooks require a supported coding agent (Claude Code, Cursor)