Building Agent Governance Into Your API Instead of Bolting It On: Policy, Audit, and CLI Surfaces

Introduction

Two announcements landed on the same day, 2026-09-28, and they reach the same conclusion from opposite directions. Nvidia shipped an Open Agent platform meant to constrain and monitor what AI agents do. Cloudflare introduced cf, an agentic CLI that hands its entire API to automated agents. Neither is a feature bump. Both treat the agent as a first-class platform principal: its own identity, its own credential lifetime, its own blast radius. That is a different thing from "a user who happens to be scripted."

This post covers the design work that framing forces — how to build agent governance into your API through policy limits, audit trails, and machine-facing surfaces, instead of bolting it on once agents already hold credentials. That cost lands on API designers rather than on the teams writing prompts. A proxy bolted on after the fact has not added governance; it has added a wrapper in front of a system that was never asked to explain itself.

What Nvidia and Cloudflare Actually Shipped

Nvidia's Open Agent platform

The public coverage describes a platform whose stated purpose is to constrain and monitor agent behaviour — a control layer an operator puts around agents, not inside them. That is the whole of what the seed material supports.

There is no published API shape, no policy schema, no configuration example, and no statement of where enforcement sits in the request path. Anything more specific than "it intends to limit agent activity" is my inference. The unanswered questions are the ones that decide whether it works: is policy evaluated at the tool-call boundary or the network boundary, does a denied action get blocked or merely logged, and does revocation interrupt work already in flight? Answering any of them needs the vendor's API reference or a reproducible lab test. As of the announcement coverage, neither exists publicly.

Cloudflare's cf agentic CLI

The Cloudflare blog post introducing cf, published 2026-09-28, states that it exposes the entire Cloudflare API to automated agents. That is the vendor describing its own product, so read it as a product statement, not an independent evaluation.

The significance is structural rather than promotional. A vendor deliberately building a non-interactive surface for machine callers has to make choices a human-facing CLI never forces: how authentication is presented without a browser, how a write is scoped to one target, whether output is stable enough to parse, and what a denial looks like to code that cannot read a sentence. Those choices are the governance surface. A CLI that assumes a person at a terminal approving each step cannot be driven by an agent under policy at all.

The common thread: agents as a distinct principal type

Both moves land on the same premise: an agent is a distinct principal type, not a session belonging to a human.

The table is deliberately thin. It records what the sources say and nothing more, because the framing is doing work the facts do not yet support. "Governance intent" describes a stated goal; it is not evidence the control is effective.

Why Bolting Governance On Afterwards Fails

The proxy-layer problem: gateways see traffic, not intent

The usual retrofit is a gateway or middleware that inspects agent traffic on the way out. It is a reasonable place to start and a bad place to finish, because the gateway sees HTTP and not intent. Reading 4,000 customer records and reading one look identical on the wire: GET, 200, application/json. To tell them apart, the gateway has to reason about the response body or the request pattern — which means rebuilding the policy engine you were trying to avoid, in the layer with the least context.

Proxies are also blind to the question that matters most during incident review: which principal authorised this. A gateway can attach a header saying "agent-42 passed through," but that is a claim by the caller, not a decision by an authority.

Identity and delegation are structural

If the agent inherits a long-lived human token, every downstream permission check answers the wrong question. The question is not "can this account do X" — the human almost certainly can. It is "did this specific agent, delegated by this specific principal, hold a scope for X at this timestamp." You cannot recover that from an inherited credential, because the credential collapses the delegation chain into a single identity.

The chain you want recorded is small and boring: who granted authority, which agent exercised it, the scope granted, the expiry. Every link should be short-lived, and it has to live in the credential itself, not in a config comment nobody re-reads.

Audit trails that cannot attribute a decision

Logs that capture a request id but not the initiating principal, the policy decision, and the tool invoked are useless in an incident review. You get an access log — a record that something happened — not an audit trail, which records who was permitted to do it and whether the answer was yes.

That distinction has a cost attached. During an incident you ask three questions: what did it touch, who authorised it, and was that within policy. An access log answers the first only.

Policy as an API Primitive

Scope, lifetime, and budget on the credential

The controls that survive contact with production live on the credential itself:

• Per-agent scopes narrower than the human equivalent. An agent that reconciles invoices gets read on invoices and write on reconciliation state, not the human's full org role.
• Short token TTLs. Minutes, not weeks. Refresh becomes a policy decision point, which is exactly where you want the check.
• Per-window action counts. A cap on mutating calls per rolling window, enforced by the issuer rather than the caller.
• Spend or resource ceilings that fail closed. When the budget is exhausted, the call is denied. It does not degrade to a cheaper path or queue for later.

Fail-closed is the part teams get wrong. A budget that degrades gracefully is a budget an agent with a retry loop will silently blow through.

Two-phase and dry-run endpoints

For destructive operations, expose a plan endpoint that returns the resolved diff plus a token the apply call must present.

const key = crypto.randomUUID(); // idempotency key, reused on retry

const plan = await api.post("/v1/deployments/plan", {
  headers: { "x-agent-principal": agentId, "idempotency-key": key },
  body: { service: "billing", image: "sha256:9f1c…" },
});
// plan.diff   → resolved change set, computed by the server
// plan.token  → single-use, expires in 5 minutes, bound to agentId

await api.post("/v1/deployments/apply", {
  headers: { "x-agent-principal": agentId, "idempotency-key": key },
  body: { planToken: plan.token },
});

Two properties justify the extra round trip. The plan token is bound to the agent that requested it, so a leaked token is not a universal key. And the idempotency key means a retried apply after a network timeout returns the original result instead of deploying twice — which matters more for agents than humans, because agents retry aggressively.

Kill switch and revocation path

Revocation is underspecified in most systems, and that underspecification is where incidents come from. Three questions decide what revocation actually means for a running agent:

1. Is in-flight work cancelled, or allowed to complete?
2. Are queued actions dropped or executed?
3. Can you revoke one agent without breaking the rest of the fleet?

A revocation path that only blocks new authentications answers none of them. If the agent already holds a valid token with twenty minutes left and the queue is not drained, "revoked" is a label rather than a state.

Unconfirmed: the public material on the Nvidia platform does not describe revocation semantics — whether it cancels in-flight work, drains a queue, or is scoped per-agent versus per-fleet. An API reference documenting the revocation endpoint's behaviour would confirm it, as would a lab test that revokes mid-run and watches what happens.

Audit Trails That Survive an Incident

Log the decision, not just the request

Commit to a fixed field set, because a schema you invent during the incident is a schema you cannot query:

• principal_id — the agent
• delegated_from — the human or service that granted authority
• policy_id and policy_version — so you can reconstruct which rules were live
• decision — allow or deny, as returned by the authority
• tool / function — the name the agent invoked
• arg_hash — a digest of the arguments
• correlation_id — ties the whole chain together
• result_status — outcome, not just intent

The argument hash earns its place because arguments carry sensitive data. Storing them in full turns your audit sink into a second copy of your customer records, with the same retention and access-review obligations and usually worse controls. A hash lets you prove the arguments at apply time matched the ones the plan was approved against, without keeping the payload.

A minimal Node/TypeScript audit wrapper

type Principal = {
agentId: string;
delegatedFrom: string;
policyId: string;
policyVersion: string;
};

async function sha256Hex(input: string): Promise<string> {
const bytes = new TextEncoder().encode(input);
const digest = await crypto.subtle.digest("SHA-256", bytes);
return [...new Uint8Array(digest)]
  .map((b) => b.toString(16).padStart(2, "0"))
  .join("");
}

export function auditedFetch(
principal: Principal,
log: (line: Record<string, unknown>) => Promise<void>,
) {
return async (input: string, init: RequestInit = {}): Promise<Response> => {
  const correlationId = crypto.randomUUID();
  const started = Date.now();
  const argHash = init.body ? await sha256Hex(String(init.body)) : null;

  const res = await fetch(input, {
    ...init,
    headers: {
      ...init.headers,
      "x-agent-principal": principal.agentId,
      "x-delegated-from": principal.delegatedFrom,
      "x-correlation-id": correlationId,
    },
  });

  await log({
    principal_id: principal.agentId,
    delegated_from: principal.delegatedFrom,
    policy_id: principal.policyId,
    policy_version: principal.policyVersion,
    tool: new URL(input, "https://placeholder.invalid").pathname,
    method: init.method ?? "GET",
    arg_hash: argHash,
    correlation_id: correlationId,
    // decision comes from the authority, not from the caller
    decision: res.headers.get("x-policy-decision") ?? "unknown",
    result_status: res.status,
    duration_ms: Date.now() - started,
  });

  return res;
};
}

Two details in that wrapper do real work. The principal travels as a header so downstream services can evaluate against the agent rather than the process, and decision is read from the response headers rather than computed locally — the caller never gets to write its own verdict into the audit record.

Retention and queryability

Audit records the agent cannot rewrite are worth more than records written through a path the agent controls. If the agent holds a token that can write to the sink, a compromised agent can also write a clean-looking history. Use an append-only sink with a separate write credential held only by the wrapper's identity, and no update or delete verb. That is a design argument, not a measurement — I have not seen evidence that any vendor in this announcement does it this way.

CLI-First Surfaces Are an API Contract

Why a CLI is a governance surface

Non-interactive callers need deterministic exit codes, machine-readable JSON on stdout, structured errors on stderr, and no prompts. A CLI that expects a human to approve each step cannot be driven by an agent under policy. Flip it around, though: once a CLI has those four properties, it becomes testable. You can assert that a denied action returns non-zero, that the error carries a correlation id, and that the stdout stream parses.

Designing for machine callers

• Stable --output json on every subcommand an agent is expected to call, with a documented schema.
• Documented exit code meanings — 0 success, 2 usage error, 3 policy denied, for example. The mapping is yours to define and publish.
• Idempotency keys on mutating verbs, accepted from the caller.
• No interactive confirmation when a policy token is present, and a hard failure when one is absent.
• --dry-run on every destructive subcommand, returning the same resolved diff the plan endpoint would.

That last pair changes behaviour. An agent can only be given authority if the surface has a way to act without a human, and it can only be given authority safely if there is a preview path.

Versioning the agent surface

Once agents depend on a surface, breaking changes become a governance problem too. If the default output drifts from JSON to a human table in a minor release, every agent parsing it fails — and it fails in a way that looks like a network error rather than a contract change. Pin behaviour behind an explicit version flag and keep the unversioned default as the human format, so machine callers must opt in and can be tracked.

A Practical Checklist for JS and TypeScript Teams

Control matrix: layer, control, and the failure it prevents

What to test before enabling an agent in production

1. Revoke mid-run. Start a multi-step agent task against a lab or staging environment, revoke the agent between steps, and confirm the remaining calls fail. This tells you whether revocation is a state or a label.
2. Exceed the budget. Run the agent past its action cap and confirm it fails closed — a denial, not a quiet step down to a cheaper path.
3. Check audit completeness. Assert that every mutating call produced exactly one record with a principal_id that resolves to a real identity and a correlation_id matching the client log.
4. Deny a policy call and read the exit code. cf --output json ... revoke --id agent_7f3a followed by a read the agent no longer holds scope for should return a documented non-zero code and a parseable error object.

For step 4, the shape to assert on looks roughly like this:

{"error":{"code":"policy_denied","principal":"agent_7f3a","policy":"r2.read","correlation_id":"b1f0…"}}

with a matching non-zero exit. Neither vendor's material in the seed specifies its exit code table, so this is a property of your own surface — define it, document it, and test it in staging rather than against a live third-party account.

What Is Confirmed and What Is Not

Confirmed

Two dated announcements, both 2026-09-28, per the source material: Nvidia's Open Agent platform, described as intended to constrain and monitor AI agents, and Cloudflare's cf agentic CLI. Cloudflare's own blog post is the primary source for the claim that cf exposes the entire Cloudflare API to automated agents. The Nvidia coverage in the seed is a CNBC report.

Unconfirmed or inferred

No public policy schema, enforcement model, or revocation semantics for the Nvidia platform appear in the provided material. The mechanics described above — where policy is evaluated, what revocation does to in-flight work, how delegation is recorded — come from general API design practice, not from a description of that product. A vendor API reference or a reproducible lab test would confirm them.

One more point worth stating plainly: a vendor's own announcement is not an independent evaluation of a control's effectiveness. "Intended to constrain" is a design goal. Whether the constraint holds against an agent actively trying to escape it is a separate claim, and nobody in this material has made it.

Conclusion

Governance belongs in the API contract as identity, scoping, and audit primitives — not in a prompt, and not only in a gateway. CLI-first surfaces make that contract testable, which is why these two announcements are related even though the products are not. If your agent governance lives in a system prompt or a proxy today, it is an add-on, and it will behave like one the first time an agent moves faster than the layer watching it.

Further Reading

• Introducing cf: the agentic CLI for the entire Cloudflare API — vendor blog, Cloudflare, 2026-09-28.
• Nvidia releases software platform to stop AI agents from misbehaving — news report, CNBC, 2026-09-28.

Both links resolve through Google News aggregation; the publisher is named with each item so the primary source is identifiable.