The Governed Agent Profile: End-to-End Control for AI Agents

A governed agent profile is what you get when an AI agent can act in the real world and every regulated action passes through enforced policy — spend limits, human approval, audit, and instant revoke. Naïve is autonomous company infrastructure built for this model: provision a profile per tenant, scope it with an Account Kit, and let the governance gateway decide on every tool call.

This post follows one agent profile from creation to revocation — the control lifecycle that complements the multi-tenant architecture playbook. For the building blocks (identity, permissions, secrets), start there; here we focus on what happens after the agent exists.

What is a governed agent profile?

An agent profile is Naïve's bundle for one agent: verified business identity, a spend-capped card, inbox and phone, and optionally a place to run — provisioned per tenant user, governed on every action, instantly revocable. "Governed" means the bundle isn't just credentials; it's credentials plus a governance gateway that sits between the agent and the real world.

Inside the agent, tools are handles, never raw secrets. When the model calls cards.charge($48), the runtime sends the call to the gateway — not to the card processor. The gateway loads policy, checks budget, and either executes, parks for approval, or denies with a structured error and a log entry.

Step 1 — Provision the profile

Give each customer's agent its own profile so isolation is structural:

const op = await naive.forUser(tenant.id).provision("support", {
  idempotencyKey: `op:${tenant.id}`,
});
await op.refresh();
if (op.status === "active") {
  const tools = await op.tools();
}

Provisioning is idempotent on idempotencyKey — a retried webhook resumes the same profile instead of forming a second entity or issuing a second card. See agent profiles in the docs.

Step 2 — Scope with an Account Kit

An Account Kit is the ceiling policy: which primitives the agent may use, per-tool limits, and which actions require human approval. Assign a kit when you provision or attach one to the tenant user — permissions are enforced at execution time, not in the prompt.

Cards, domains, verification, formation, and connecting new third-party apps default to requiring approval for agent calls. You opt out per primitive in the kit if a tier should run autonomously.

Step 3 — Spend within budget

Real-world spend and platform usage share one combined budget on the agent profile. Hard caps reserve atomically before execution — no concurrency race — and return 403 budget_exceeded when exhausted. Soft caps route to the approvals queue instead of failing silently.

For card spend specifically, limits are set in cents on the Account Kit. Prepaid gift cards carry a published $150 maximum (per published docs); managed virtual cards require a cardholder and support higher limits. The full spend/approval/revoke pattern is in spend caps, approvals & revocation for AI agents.

Step 4 — Gate sensitive actions on approval

When an agent hits a gated action, the API freezes the request:

import { isPendingApproval } from "@usenaive-sdk/server";
 
const res = await alice.cards.create({ name: "Ads", spendingLimitCents: 50000 });
if (isPendingApproval(res)) {
  // res.approval_id — surface to a human
  await alice.approvals.approve(res.approval_id);
}

The agent receives 202 pending_approval, not a completed charge. A human approves; the API replays the frozen action. Deny and the action never runs. Step-by-step setup is in how to add human approval to an AI agent.

Step 5 — Audit every call

Governance requires observability, so the control plane records every tool call, spend decision, and approval outcome — OpenTelemetry-shaped, exportable to Langfuse or Datadog with no extra module. Per-user logs give you an immutable trail: what the agent attempted, what the gateway allowed, and what a human approved.

This is the audit half of autonomous company infrastructure: you can explain why a charge happened, not just that it did.

Step 6 — Delegate with revocable sessions

Don't hand an untrusted runtime your workspace key. Mint a short-lived MCP session scoped to one tenant user:

const session = await naive.forUser(alice.id).sessions.create({ ttlMs: 15 * 60 * 1000 });
// session.mcp.url + session.mcp.headers → hand to your MCP client

Sessions default to 15 minutes, max 24 hours, and are instantly revocable (per published docs). The session's tool list is filtered by the user's Account Kit. See delegated, revocable MCP sessions.

Step 7 — Revoke instantly

When something goes wrong — prompt injection, runaway spend, customer offboarding — cut access in one call:

await op.revoke();

Revoke suspends the agent profile. The governance gateway denies all further tool calls, releases the runtime slot, and cascades to sub-agents. Revoking a parent profile kills the whole multi-agent system. How to revoke an AI agent's access instantly walks through the surfaces (SDK, REST, CLI, MCP).

Where does the agent run?

Governance is constant regardless of hosting. Bring your own runtime (the lead path): inject op.tools() into LangGraph, Eve, or your loop — every action still hits the gateway. Naïve-hosted (optional): declare a runtime pool and start agents on microVMs with credentials injected at boot, never on the agent's filesystem. Compare both in hosted vs bring-your-own runtime for AI agents.

What are the common pitfalls?

• Governance in the prompt — "Don't spend more than $50" is bypassable. Caps and approvals must be server-side.
• Long-lived workspace keys in agents — leak once, lose everything. Use per-user sessions with TTL and revoke.
• Revoke as an afterthought — if cutting access requires a deploy or key rotation, you won't do it under pressure. revoke() must be one call.
• Audit as a bolt-on — if logs don't capture gateway decisions, you can't reconstruct an incident.

Where to go next

That's the governed lifecycle: provision, scope, spend within budget, approve sensitive steps, audit, delegate with sessions, revoke.

Proof in practice

• Build an agentic accounts-payable platform — approval-gated card spend
• Build a bring-your-own-agent platform — MCP sessions on an external runtime
• Build an agentic robo-advisor — trading under policy

The governance gateway docs are the architecture reference; introducing governance covers the /governance primitives (approvals, logs, sessions, jobs). Start with one gated action — issue a card, connect an app — and wire approval before you widen the kit.