Agent Baseline Guide: Implementing 35 AI Agent Controls

The practical way to use Agent Baseline is to map existing enterprise controls to its six outcomes, identify uncovered agent-specific failure paths, and fund a phased evidence plan. Do not claim “Agent Baseline compliant.” The project itself rejects that interpretation, invites public comment through September 30, 2026, and discloses both commercial interests and unfinished evidence work.

Start with the draft boundary

Agent Baseline describes minimum security outcomes for agents that can affect enterprise resources or business outcomes. It is intentionally organized by what must be true—discover, constrain, authorize, observe, validate and respond—rather than by product category.

As of July 31, 2026:

This matters because a gap analysis can remain useful while the vocabulary changes, but an audit citation such as AUT-04 becomes ambiguous if it omits the reviewed draft and commit.

Map the six outcomes to accountable evidence

The machine-readable catalogue currently distributes controls as follows:

The count is not a maturity score. Nine Authorize controls do not make Authorize more important than four Constrain controls. A program with perfect inventory and no revocation path still fails under pressure; a program with a kill switch and no ownership record may not know what to stop.

Use three questions for every row:

1. What must be true for this outcome in our environment?
2. Which enforcement point makes it true?
3. Which independent record would convince a reviewer that it happened?

Agent programs built around business-facing workflows can also borrow the ownership and boundary patterns in the OpenAI Presence enterprise agents guide. Treat vendor product controls as implementations to assess, not as proof that an outcome is complete.

Build a minimum viable rollout

Do not launch a 35-workstream compliance project. Build a dependency-aware sequence that gives teams visibility, containment and a stop path before expanding autonomy.

This ordering is AgentPedia's implementation synthesis, not an ordering mandated by the draft. A high-impact financial or production agent may need independent approval and outcome validation in phase 1. Use the risk tier to pull controls forward, never to defer basic ownership or stop capability.

Minimum launch gate

Before a new agent receives non-read-only access, require:

• an authoritative agent ID, owner, purpose, risk tier and approved version;
• an explicit component and effective-access map;
• a confined runtime and deny-by-default network policy;
• task- and time-bounded credentials kept outside model context;
• stable run IDs across model, tool, policy and target-system events;
• adversarial tests derived from the actual tools and data;
• a named approver for consequential actions;
• a rehearsed stop, revocation and evidence-preservation path.

For VPS-hosted agent products, the Hermes Agent deployment guide provides a concrete infrastructure surface on which to apply these outcomes.

Create an evidence model before collecting screenshots

The draft catalogue currently gives each control an ID, outcome, title, type, status and requirement. Its current per-control records do not provide a complete evidence or framework-crosswalk schema, even though CONTRIBUTING.md requires an evidence-of-achievement line for a control and asks contributors to add crosswalks separately.

Your internal evidence record should be stricter than a screenshot folder:

# Example internal evidence schema; not an Agent Baseline conformance format.
control_ref:
  id: AUT-04
  baseline_version: "1.0-draft"
  source_commit: "<pinned-git-sha>"
scope:
  agent_id: "agent:finance:reconcile-v3"
  deployment: "prod-eu"
  owner: "finance-platform"
implementation:
  enforcement_point: "credential-broker/policy-v18"
  expected_state: "JIT credential; invoice API only; 15 minute TTL"
test:
  procedure_id: "AB-AUT04-NEG-003"
  executed_at: "2026-07-31T00:00:00Z"
  result: "pass"
  negative_case: "expired token denied"
evidence:
  immutable_uri: "evidence://agent-runs/run_..."
  digest: "sha256:<digest>"
  target_log_id: "invoice-api/event_..."
review:
  reviewer: "security-assurance"
  decision: "accepted"
  expires_at: "2026-10-31T00:00:00Z"
limitations:
  - "Does not cover emergency break-glass identity"

Keep four things separate:

The GitHub Copilot code review and MCP guide is useful when mapping repositories, skills and MCP servers into component inventory and artifact review.

Run a gap assessment that survives draft changes

Build the assessment around stable business capabilities, then attach the current draft IDs. This lets you remap when the catalogue changes.

Business workflow:
Agent/deployment IDs:
Risk tier and rationale:
Data classifications:
Tools and targets:
Maximum reversible impact:
Maximum irreversible impact:

Outcome:
Draft control reference + source commit:
Required state:
Current enforcement:
Evidence location:
Negative test:
Owner:
Gap:
Remediation:
Due date:
Residual risk:
Exception approver and expiry:

Use a status vocabulary that describes evidence, not sentiment:

Avoid rolling these into a single percentage. “80% complete” hides whether the missing 20% is inventory paperwork or the production kill switch.

Example gap row

Implement and test controls as a connected system

Controls can pass in isolation and fail in combination. A short-lived credential is weak if the model can request another without approval; a sandbox is weak if an MCP server holds a broad production token.

Implementation checklist

• Inventory agent definitions, deployments, models, instructions, skills, plugins, MCP servers and tools.
• Resolve runtime versions rather than recording only desired versions.
• Map direct and transitive credentials, targets, data and actions.
• Enforce registered, risk-classified and validated versions at admission.
• Keep code execution separate from host credentials and unrelated workloads.
• Grant network, filesystem, compute and duration through versioned profiles.
• Propagate initiating identity and task context across delegation hops.
• Issue short-lived, resource-scoped credentials after authorization.
• Fail closed when identity, policy, approval or target state cannot be verified.
• Correlate agent intent with executed target-system actions and outcomes.
• Test generated code and configuration to the same gates as human artifacts.
• Quarantine compromised versions and downstream dependencies.

Verification checklist

The OpenAI–Hugging Face evaluation security incident is a useful case study in why benchmark intent, network containment and the target system's observed outcome must be correlated.

Account for draft governance and commercial interests

The repository's provenance file is unusually direct: Docker, Keycard and Snyk convened the work, all sell products in the area, and none is a complete implementation by the draft's own category test. It also says Discover, Observe and Respond are less developed than the outcomes tied more closely to conveners' products.

That disclosure improves interpretability; it does not establish independence, completeness or endorsement.

The repository licenses prose and figures under CC BY 4.0 and the schemas plus controls.yaml under Apache-2.0. It also records pending legal confirmation about license treatment if the work is donated later. State the license of the exact material you reuse.

Prepare the next review

Use the draft now if it helps expose missing controls, but schedule a remap at public-comment close and again at v1.0. Your next review packet should contain:

1. the pinned draft commit and its 35-control inventory;
2. a change report against the prior assessed revision;
3. outcome-level owners and control-level enforcement points;
4. current positive and negative test evidence;
5. open exceptions with accountable owners and expiries;
6. the incident and revocation exercise results;
7. unresolved draft ambiguities sent back as public issues where appropriate.

The useful deliverable is not a logo. It is a defensible chain from business intent to bounded authority, executed action, verified outcome and tested recovery.

Official sources

Agent Baseline

• Agent Baseline site — project framing and six-outcome argument
• Control catalogue — human-readable control listing
• Agent Baseline white paper — draft rationale, scope and figures
• Agent Baseline GitHub repository — status, dates, governance, provenance and licensing
• Canonical controls.yaml — current machine-readable outcomes and 35 draft controls
• Provenance and commercial interests — conveners, interests, asymmetry and non-independence disclosure
• Contribution rules — per-control evidence expectation and contribution process
• Versioning policy — identifier lifecycle and v1.0 freeze

Related AgentPedia guides

• OpenAI–Hugging Face evaluation security incident
• OpenAI Presence enterprise agents guide
• Hermes Agent VPS deployment guide
• GitHub Copilot code review, skills and MCP guide