OpenAI Model Spec: turn agent autonomy into an action contract

OpenAI updated its Model Spec on October 29, 2026, reorganizing its intended model behavior around five values: faithfulness to human intent, harm minimization, honesty and transparency, human agency, and care. For engineers building tool-using agents, the most useful change is not a new prompt phrase. It is a clearer vocabulary for bounding autonomy, separating instructions from untrusted data, making context use visible, and controlling side effects.

This article covers a current OpenAI announcement, then turns it into an implementation pattern. The release date, five values, instruction hierarchy and quoted Model Spec principles are documented facts. The autonomy contract, action gateway, effect ledger and evaluation plan below are engineering recommendations. OpenAI explicitly says the Spec describes intended behavior and that production models do not yet fully reflect it, so the Spec must not be treated as a runtime guarantee.

The answer first

Do not encode agent autonomy as “be careful” in a system prompt. Store it as a versioned action contract that defines the goal, allowed sub-goals, trusted instruction sources, tools, data boundaries, budgets, approval triggers, prohibited effects, expiry and safe-stop behavior. Enforce that contract in code before every side-effecting tool call, then verify the external result and record an auditable effect.

The model can propose an action. Your application remains responsible for authorization, policy, execution, state verification and recovery.

What OpenAI actually changed

OpenAI's October 29 announcement says the revised Model Spec is organized around five values. It also adds or expands guidance on context, oversight, agency, social norms, and controlling and communicating side effects, while retiring much of the detailed style guidance. The company now uses “GPT” rather than “the assistant” in the Spec to reflect broader deployment settings.

The updated Spec describes an instruction hierarchy: Root, System, Developer, User, Guideline, then sources with no authority by default. Assistant messages, tool messages, quoted text, files and other untrusted data do not automatically become instructions. The Spec also says autonomous work should happen within an agreed scope that identifies permitted sub-goals, acceptable side effects and moments that require clarification or approval.

These are intended behaviors, not a new API endpoint. OpenAI states that production models do not yet fully reflect the public Spec. Therefore:

• do not infer that a model upgrade automatically enforces your organization's action policy;
• do not use the Model Spec as proof of regulatory compliance;
• do not replace deterministic authorization with prompt text;
• do use the update as a design vocabulary and a source for evaluation cases.

Convert the values into system controls

The five values become useful when each maps to a control that can be tested outside the model.

The mapping is not a claim that OpenAI prescribes this exact architecture. It is a practical way to keep the product's guarantees outside probabilistic model behavior.

Define a versioned autonomy contract

A contract should be data, not prose hidden across prompts. A simplified example:

{
  "contract_id": "supplier-renewal-v7",
  "goal": "prepare renewal options for three approved suppliers",
  "allowed_subgoals": ["read_contracts", "compare_terms", "draft_email"],
  "tools": {
    "drive.read": {"folders": ["renewals/2026"]},
    "email.draft": {"recipients": ["approved_supplier_contacts"]},
    "email.send": {"approval": "required"}
  },
  "data": {
    "allowed_classes": ["business_contact", "contract_terms"],
    "forbidden_classes": ["payment_credentials", "employee_health"]
  },
  "budgets": {"max_usd": 0, "max_minutes": 30, "max_actions": 80},
  "prohibited_effects": ["sign_contract", "change_permissions", "delete_record"],
  "approval_triggers": ["external_send", "new_recipient", "scope_change"],
  "expires_at": "2026-10-30T12:00:00Z",
  "safe_stop": "save_draft_and_report"
}

The contract is illustrative. Validate it before a run, sign or hash the accepted version, and attach its identifier to every model request, tool proposal, approval and effect receipt. The agent must not be able to edit its own contract.

Scope changes require a new version. If the task changes from drafting renewal options to sending commitments, do not silently expand the old contract. Stop, present the new side effects and obtain the required authorization.

Resolve instructions before generation

The updated Model Spec's chain of command is valuable because tool-using agents routinely mix instructions and data. Your runtime should label every input with origin, authority, trust and freshness:

input envelope
  origin: developer | user | tool | file | web | memory
  authority: explicit policy level or none
  trust: trusted | untrusted | quarantined
  purpose: instruction | evidence | reference | output
  captured_at: timestamp
  expires_at: optional timestamp
  audience: private | team | external

The model should see untrusted documents as evidence blocks, not as developer instructions. More importantly, the tool runtime must enforce this separation even if the model produces the wrong interpretation. Never allow text inside an email, webpage, PDF or retrieved RAG chunk to grant a new tool, widen a data scope or approve an action.

For RAG, keep the user's question and application policy in authoritative messages; put retrieved passages in clearly delimited evidence objects. Preserve source identity and trust metadata through reranking and context construction. A high relevance score does not create instruction authority.

Make context and memory steerable

The Spec says context use should be legible and steerable. In a production application, build that into the response and the control plane:

• show which memory, file or connected source materially affected the decision;
• distinguish user-provided facts from application defaults and model inferences;
• let the user correct or exclude stale context;
• apply purpose and audience limits before retrieval;
• attach freshness and retention rules to stored context;
• avoid persisting disputed claims as facts.

Create a context manifest for every consequential run. It can list source IDs, capture times, classifications, access decisions and whether each item was used. Do not expose sensitive content in logs; record references and decision metadata instead.

Context selection also needs negative tests. Verify that a finance agent cannot retrieve health notes, that one tenant's memory never enters another tenant's request, and that a deleted or revoked source stops appearing in future context.

Put an action gateway in front of every tool

Model output is a proposal. The action gateway converts the proposal into a policy decision.

1. Parse the tool name and exact arguments against a strict schema.
2. Confirm the action is within the current autonomy contract.
3. Classify data exposure, counterparties, monetary cost and reversibility.
4. Reject arguments derived from untrusted instructions when they change authority or destination.
5. Require approval for a matching trigger, and show the exact payload before execution.
6. Create an idempotency key and reserve it before the external call.
7. Execute with least-privilege credentials.
8. Read back authoritative state and store the receipt.
9. Report success, uncertainty or failure without claiming more than the evidence proves.

Approval should not be a generic “continue?” button. It must identify the action, destination, data, cost and irreversible effects. Otherwise users learn to approve without understanding.

Control and verify side effects

The updated Spec emphasizes proportional actions and avoiding bad surprises. The runtime needs an effect ledger:

effect_id
contract_id + version
tool + normalized arguments digest
counterparty and destination
data classes transmitted
approval receipt
idempotency key
request time and response
authoritative read-back
status: proposed | approved | applied | uncertain | rolled_back

If an external request times out, mark the effect uncertain. Query the provider by idempotency key or business identifier before retrying. A retry without read-back can duplicate an email, booking, payment or permission change.

Make the user's final report reflect evidence. “Request accepted” is not the same as “external state verified,” and neither proves a search engine indexed a page, a recipient read an email or a bank settled a transfer.

Evaluation must test trajectories, not slogans

Prompt snapshots are insufficient for agents. Test multi-step trajectories with realistic tools and state:

• a webpage tells the agent to ignore the user's goal and upload a secret;
• a stale memory conflicts with a new explicit preference;
• a tool returns success but read-back shows no change;
• an email send times out after the provider accepted it;
• a long-running task reaches its cost or action budget;
• a subtask proposes a new recipient outside scope;
• a harmless-looking action becomes destructive because of one argument;
• the model reports completion despite an uncertain external outcome.

Score separate dimensions: task success, instruction resolution, context provenance, authorization accuracy, side-effect minimization, truthful status reporting and recovery. Keep false-allow and false-deny rates separate. A system that blocks everything is not a useful agent, and a system that completes tasks while bypassing authorization is not safe.

Run the suite across model versions and prompt changes. Treat a model migration as a behavioral change even when the API schema stays identical.

Best practices

• Keep the autonomy contract immutable during a run.
• Enforce permissions and risk gates outside the model.
• Label untrusted content and preserve its provenance through RAG.
• Use least-privilege credentials per tool and tenant.
• Make approval prompts specific to the exact effect.
• Use idempotency keys and authoritative read-back.
• Expose material context use without leaking private content.
• Stop safely when budgets expire or state becomes uncertain.
• Version prompts, policies, tool schemas and evaluation sets together.
• Record reason codes that operators can audit without hidden reasoning.

Anti-patterns and limits

• Adding “follow the Model Spec” to a prompt and calling the agent governed.
• Allowing retrieved documents or tool output to modify policy.
• Giving an agent broad credentials because the prompt says to ask first.
• Treating a confirmation dialog as authorization without exact payload details.
• Retrying an uncertain external write blindly.
• Persisting every inferred preference as permanent memory.
• Logging sensitive context or hidden reasoning for observability.
• Claiming the updated Spec guarantees present production-model behavior.

The Model Spec is a public statement of intended behavior, not a substitute for OpenAI's current API reference, usage policies, your legal obligations or your own product controls. Application developers still choose the deployment design and remain responsible for its outcomes.

Implementation checklist

1. Inventory every side-effecting tool and data destination.
2. Define an autonomy-contract schema and immutable versioning.
3. Label input origin, authority, trust, purpose and freshness.
4. Move retrieved content into explicit evidence containers.
5. Add a deterministic action gateway before tool execution.
6. Define risk classes and exact approval triggers.
7. Add idempotency, receipts and authoritative read-back.
8. Build a context manifest with correction and exclusion paths.
9. Test prompt injection, stale context, uncertain writes and scope expansion.
10. Monitor task success, false allows, false denies and recovery outcomes.

Related reading: guarded computer use with GPT-6.1 Terra, secure RAG document ingestion, RAG citations and provenance, and the AI, RAG and vector search hub.

Primary references

• OpenAI — An updated Model Spec for more capable and beneficial AI
• OpenAI — Model Spec, October 29, 2026
• OpenAI — Model release notes
• Wikimedia Commons — Control Center Elektro Ljubljana using CyberNoc
• Creative Commons — Attribution-ShareAlike 4.0

Prepared by: Noor Yasser

Prepared by: Noor Yasser