Enterprise Governance

Enterprise organizations deploying AI agents face a fundamental problem: the teams responsible for security, privacy, and compliance need to enforce constraints that the agent authors should not see, cannot modify, and may not even know exist.

The Governance Gap

Consider an enterprise where:

• The security team mandates PII redaction on all agent outputs
• The privacy team requires data retention limits for agents handling user data
• The cost management team caps total spend across all agents
• The compliance team requires human approval for any agent that modifies production systems

Agent Format's constraints section alone is insufficient because:

1. Visibility: Governance policies may contain sensitive logic that should not be in .agf.yaml files
2. Centralization: Policies are scattered across hundreds of YAML files instead of a central registry
3. Consistency: No mechanism for governance teams to enforce minimum standards across all agents
4. Enforcement: Nothing prevents an Agent Owner from omitting constraints entirely

The Two-Layer Constraint Model

Agent Format solves this with a two-layer model:

Layer	Authored By	Visibility	Storage	Example
Layer 1: Agent Constraints	Agent Owner	Visible in .agf.yaml	Inline in YAML	budget.max_token_usage: 50000
Layer 2: Governance Policies	Governance Team	Opaque to Agent Owner	External Policy Registry	PII redaction, cost ceiling, approval workflow

Layer 2 has two sub-layers:

Layer 2A: Referenced Policies

The .agf.yaml may optionally reference governance policy IDs for documentation and auditability:

constraints:
  governance_policies:
    - policy_ref: org.security.pii-redaction-v2
      description: Required for all customer-facing agents

The Agent Owner can see the policy IDs but not the policy details (what patterns it detects, what thresholds it uses).

Layer 2B: Implicit Policies

The Runtime Owner applies policies based on namespace, data classification, or labels without any reference in the .agf.yaml. The Agent Owner does not know these policies exist.

Examples:

• "All agents in the customer-facing zone must have PII redaction"
• "All agents with label domain: finance must have a cost ceiling"
• "All agents with data_classification: confidential require approval for output"

Constraint Composition

The composition algorithm extends tighten_only_invariant to governance:

Constraint Type	Composition Rule	Example
Numeric limits (budget, calls)	min(all values) -- tightest wins	Agent: 100k tokens, Policy: 50k --> 50k
Boolean flags	AND -- if any says restricted, it's restricted	Both true --> true
Allowlists (tools, domains)	intersection -- only items in ALL lists	Agent: [A,B,C], Policy: [B,C,D] --> [B,C]
Denylists	union -- all denied items from all sources	Agent denies [X], Policy denies [Y] --> [X,Y]
Guardrails	union -- all guardrails apply	Agent: none, Policy: PII filter --> PII filter
Approval requirements	union -- if any requires, all require	Agent: none, Policy: requires --> required

The algorithm is order-independent (commutative and associative) -- the Runtime Owner does not need to specify priority ordering between policies. The tighten-only invariant ensures the most restrictive combination always wins.

Worked Example: Constraint Composition

Consider an agent with the following Layer 1 constraints and two matched governance policies:

# Layer 1: Agent Owner declares
constraints:
  budget:
    max_token_usage: 100000
    max_duration_seconds: 600
  limits:
    max_tool_calls: 200

# Layer 2A: Referenced policy -- org.finance.cost-ceiling-q1
#   max_token_usage: 50000
#   max_duration_seconds: 900

# Layer 2B: Implicit policy -- org.security.production-baseline
#   max_token_usage: 75000
#   max_tool_calls: 150
#   approval required on all external MCP tools

Step-by-step composition:

Constraint	Layer 1	Policy A	Policy B	Effective	Rule
max_token_usage	100,000	50,000	75,000	50,000	min(all)
max_duration_seconds	600	900	--	600	min(all) -- Layer 1 is already tighter
max_tool_calls	200	--	150	150	min(all)
External tool approval	none	--	required	required	Union -- any requires = all require

The effective constraints are the tightest combination across all layers. Note that:

• Policy A's max_duration_seconds: 900 does not relax Layer 1's 600 -- tighten-only means min(600, 900) = 600.
• The composition order does not matter: compose(Layer1, compose(A, B)) = compose(compose(Layer1, A), B) = compose(B, compose(Layer1, A)).

Policy Resolution Flow

When the Runtime Owner executes an agent, the following six-step process resolves the effective constraints:

Step-by-step breakdown

1. Parse .agf.yaml -- Extract Layer 1 constraints (inline) and any governance_policies[].policy_ref references.
2. Resolve Referenced Policies (Layer 2A) -- For each policy_ref, fetch from the Policy Registry. If required: true and not found, the agent does not execute. If required: false and not found, emit a warning and skip.
3. Resolve Implicit Policies (Layer 2B) -- Query the Policy Registry for policies matching the agent's metadata.namespace, metadata.labels, and metadata.data_classification.
4. Compose Effective Constraints -- Start with Layer 1, merge each resolved policy using tighten-only semantics, and produce the EffectiveConstraints.
5. Configure Enforcement -- Wire budget limits, guardrails, and approval providers. Record all applied policies in the execution trace.
6. Execute Agent -- The agent runs under the composed effective constraints.

Fail-Closed Semantics

If a referenced governance policy with required: true cannot be resolved from the Policy Registry, the agent does not execute. This is essential for enterprise governance -- a security policy that silently stops working is worse than no policy at all.

Governance Policies Are Always Tighten-Only

Even if the Agent Owner sets tighten_only_invariant: false (which controls parent-child constraint propagation), governance policies are always tighten-only. The Agent Owner controls their own constraint hierarchy; the Governance Team controls the organizational overlay. The Agent Owner cannot relax governance.

The Agent Owner's View

From the Agent Owner's perspective, implicit governance policies are invisible:

# The Agent Owner writes this.
# They have NO idea the Runtime will also apply:
#   - org.security.pii-redaction-v2 (because namespace=customer-facing)
#   - org.finance.cost-ceiling (because zone=customer-facing)
#   - org.compliance.audit-logging (applied to all agents)

metadata:
  id: customer_support_agent
  name: Customer Support Agent
  namespace: customer-facing.support
  data_classification: confidential
  labels:
    environment: production
    sensitivity: pii

constraints:
  budget:
    max_token_usage: 100000
    max_duration_seconds: 600

The effective constraints at runtime are the composition of Layer 1 + all matched policies -- but the Agent Owner's YAML is unchanged. The governance layer is entirely transparent to the agent author, enforced by the runtime, and managed centrally by governance teams.