AI agent attribution

Know which tool path issued the query.

The MCP server records an agent ID, environment, workspace, and host context supplied by the local deployment. This separates activity without overstating it as access authentication.

Why this exists

Attribution today; verified workload identity next

SB_AGENT_ID and related settings give each MCP installation a stable label. Without one, Safe Boundary derives a best-effort local identity so evaluation audit remains useful.

The database connection still uses DATABASE_URL. An agent key can authenticate the optional audit uplink, but it does not replace or revoke the database credential.

What it does

Concrete controls, stated precisely.

01

Stable agent label

Attach a configured agent and environment to query, mask, and block events.

02

Best-effort fallback

Derive local host and workspace context when explicit metadata is absent.

03

Audit uplink authentication

Use an agent or console key to protect best-effort console delivery.

How it works

A visible enforcement sequence.

  1. 1

    Name

    Assign a stable SB_AGENT_ID to the MCP deployment.

  2. 2

    Contextualize

    Add environment and workspace metadata.

  3. 3

    Enforce

    Run database tool calls through the local MCP server.

  4. 4

    Correlate

    Filter audit events by agent attribution and outcome.

Protected when

  • Audit separation between MCP installations
  • Local policy enforcement on the named tool path
  • Authenticated optional console delivery

Important boundaries

  • The label is local input, not cryptographic workload proof
  • Revoking the audit key does not revoke DATABASE_URL
  • Per-agent policy and durable cross-session quotas are not current capabilities

Continue the story

Related Safe Boundary pages

Test the boundary on a real access path.

Start in observe mode, validate the policy against representative traffic, and move to enforcement with explicit bypass controls.