Govern agents through authority, ownership, evidence, and change control

Govern the complete system, not only the model

The governance object includes models, prompts, retrieval, memory, tools, identity, orchestration, policies, human interfaces, providers, monitoring, and downstream effects. A model inventory alone will miss the parts of an agentic system that hold authority or create irreversible state.

NIST's Govern, Map, Measure, and Manage structure supports a lifecycle view in which responsibilities and context remain connected to evaluation and operational risk management. [S1]

Create an accountable system record

Every agentic system should have a durable record with a stable identifier, owner, purpose, prohibited uses, affected people, lifecycle state, dependencies, data classes, tool capabilities, review date, and current release decision.

• Business owner responsible for the outcome
• Technical owner responsible for architecture and operation
• Security, privacy, legal, procurement, or domain reviewers where applicable
• Human authority roles for approval, override, appeal, and incident response
• Named retirement and records-retention owner

Separate policy from execution authority

The model can interpret policy text, but it should not be the sole policy decision point for consequential action. External controls should evaluate identity, capability, resource, context, and limits before a tool call is executed.

MCP authorization guidance uses OAuth-based protected-resource patterns for transport authorization. Enterprise-managed authorization can centralize approved access, but the organization still needs task-level business authorization and least privilege. [S3] [S4]

Use delegated authority that narrows

When a person delegates work to an agent, and that agent delegates to another service or participant, each hop should preserve the original principal and narrow rather than widen the allowed action. Research on authenticated agent delegation emphasizes scoped permissions, verifiable identity, and auditability. [S5]

Make change control evidence-based

A material change to model, prompt, retrieval source, tool, permission, data boundary, orchestration, provider, or human-review design should trigger a defined level of reassessment. Change control should specify which tests rerun, who approves, and whether the release state returns to conditional or hold.

Operate a governance cadence

Governance is not one approval meeting. It includes intake, design review, pre-release evidence, post-deployment monitoring, incident review, periodic assurance, exception expiry, and retirement. NIST's 2026 monitoring report identifies ongoing challenges such as fragmented logging, drift, changing context, and scaling human monitoring, which reinforces the need for an explicit operating cadence. [S2]

Minimum governance artifacts

A useful minimum set includes the system record, architecture and data-flow map, authority matrix, evaluation plan and results, threat model, release decision, monitoring specification, incident and rollback plan, exception register, change history, and retirement record.

Governance anti-patterns

Avoid a central committee that owns no operational decision, an inventory that excludes tools and downstream effects, approval without representative evaluation, permanent exceptions, human review without capacity, and a kill switch that depends on the same failing control plane.

Research boundary

This article describes an engineering operating model. It is not legal advice, certification, a complete NIST implementation, or a substitute for sector-specific review. Governance depth must reflect the actual use, consequences, obligations, and environment.