The Context Contract: How Enterprise AI Decides What It Is Allowed to Know and Do

Enterprise AI is moving from answering questions to influencing decisions and taking action.

That shift changes the central architecture question.

It is no longer enough to ask whether the model can produce a useful answer. Enterprises must determine what the system was allowed to know, which evidence it was allowed to trust, which tools it was allowed to use, and which actions it was allowed to take for this user, purpose, and moment.

Most AI implementations express these boundaries indirectly. They are scattered across system prompts, retrieval filters, identity platforms, API scopes, workflow rules, safety policies, and application code. Each control may be reasonable on its own, yet the AI system has no single runtime definition of the boundary it must respect.

This is the missing role of the context contract.

A context contract is an explicit, machine-enforceable agreement that defines the information, authority, actions, and evidence available to an AI system for a specific task. It sits between user intent and model reasoning. Its purpose is not to make the model more intelligent. Its purpose is to make the complete system more appropriate, secure, and accountable.

Why prompts are not contracts

A system prompt can describe expected behaviour. It cannot, by itself, enforce enterprise authority.

Consider an AI assistant asked to investigate a delayed customer order. The prompt might say: “Use approved sources, protect customer information, and do not take action without authorization.” Those instructions are sensible, but they leave critical questions unresolved:

• Which customer records may this employee access?
• Which source is authoritative when the CRM and order platform disagree?
• Which policy version applies to this market and date?
• Can the assistant issue a refund, or only recommend one?
• What value threshold requires managerial approval?
• What evidence must be recorded before an action occurs?
• Which retrieved content is data, and which content is an instruction?

Natural-language guidance is not the same as an enforceable boundary. Models interpret instructions probabilistically. Enterprise authorization must remain deterministic at the point of access and action.

Research on instruction hierarchy recognizes the need to distinguish privileged instructions from lower-trust content 6. OWASP similarly identifies prompt injection as a system risk: untrusted content can alter behaviour, disclose information, or trigger unauthorized functionality 3. A context contract turns those concerns into an architecture responsibility rather than leaving them to prompt wording.

What the context contract governs

The context contract should answer seven questions before the system reasons or acts.

1. Who is asking?

The system needs more than a user identifier. It needs the relevant enterprise identity context: role, organizational unit, geography, entitlements, delegation, authentication strength, and any temporary restrictions.

Identity is not descriptive metadata. It changes what information and actions are permissible.

2. What is the legitimate purpose?

The same data may be appropriate for one purpose and inappropriate for another. An employee may be permitted to view customer contact information to resolve a delivery issue but not to use it for unrelated analysis.

The contract should bind access to a declared task or workflow purpose. This makes purpose a runtime control rather than a statement buried in governance documentation.

3. What evidence is authoritative?

Relevance is not authority.

A vector search can return a semantically similar document that is outdated, superseded, restricted, or intended for another jurisdiction. The contract therefore needs source rules: approved repositories, document types, effective dates, ownership, confidence thresholds, conflict handling, and freshness requirements.

This supports the NIST AI RMF principle that context, intended use, risks, and limitations should be understood and documented, and that governance should operate across the AI lifecycle 1.

4. What may enter the reasoning context?

The contract controls the assembled context package—not only retrieval.

It can specify:

• mandatory facts that must be present;
• prohibited or sensitive attributes that must be excluded;
• maximum age for operational data;
• how conflicting evidence is represented;
• separation between trusted instructions and untrusted content;
• ordering and compression rules;
• missing-evidence behaviour;
• citation and provenance requirements.

The result is a bounded evidence package whose contents can be inspected and evaluated.

5. Which tools and actions are permitted?

Tool access should be granted per task, not inherited from everything the application can technically reach.

OWASP describes excessive agency as the combination of excessive functionality, excessive permissions, or excessive autonomy 4. The architectural response is least privilege: expose only the minimum tools, functions, and scopes necessary for the current purpose.

An order-investigation assistant might receive read access to order events and shipment status, but no refund or cancellation capability. If a refund is later justified, the system can request a separately authorized action contract.

6. When is human approval required?

Human oversight becomes useful only when the architecture defines its trigger and authority.

The contract should identify:

• decisions the AI may make automatically;
• decisions it may recommend but not execute;
• thresholds requiring confirmation or dual approval;
• ambiguity and confidence conditions requiring escalation;
• the accountable role for each approval;
• the evidence the reviewer must see.

This avoids the weak pattern of adding a generic “human in the loop” after the system has already assembled inappropriate context or exceeded its authority.

7. What must be recorded?

Every material output should be reconstructable.

The contract can require a record of the user and purpose, context sources and versions, policy decisions, model and configuration, tools invoked, approvals received, action taken, and resulting outcome. W3C PROV-O provides a standard vocabulary for representing relationships among entities, activities, and agents, which is useful for designing this provenance layer 5.

Auditability should not mean logging everything indefinitely. The contract must also apply privacy, retention, and access rules to the evidence it creates.

A context contract has two halves

The most useful design separates admission from execution.

EAINE — Context Contract Architecture · EAINE original AI-assisted architecture illustration

The admission contract

The admission contract decides what may enter the AI interaction.

It validates identity and purpose, selects permitted sources, applies policy, evaluates freshness, isolates untrusted content, identifies missing evidence, and assembles a structured context package.

Its output should contain both information and control metadata. A policy document, for example, should arrive with its authority, version, effective date, jurisdiction, sensitivity, and citation—not as anonymous text.

The execution contract

The execution contract decides what may leave the reasoning process as an enterprise action.

It validates tool calls, parameters, permissions, value thresholds, approval requirements, idempotency, rate limits, and downstream policy. The model may propose an action, but the execution boundary independently determines whether that action is allowed.

This follows the logic of zero trust architecture: do not grant broad implicit trust; evaluate access per request and grant only the minimum privileges required 2. Applied to AI, the reasoning engine is not the authority. It is a consumer of explicitly granted context and a proposer of explicitly mediated actions.

The runtime sequence

A practical context-contract flow can be implemented in eight steps:

1. Interpret intent. Classify the requested task and identify ambiguity.
2. Resolve identity. Establish user, role, delegation, authentication, and applicable organizational context.
3. Load policy. Select the rules governing data access, source authority, tool use, escalation, and retention.
4. Assemble evidence. Retrieve only permitted sources and attach provenance, freshness, confidence, and conflict metadata.
5. Issue the contract. Create a bounded, time-limited context package and permitted-action set for this interaction.
6. Reason within the boundary. Give the model trusted instructions, clearly separated evidence, tools, and required output structure.
7. Mediate every action. Revalidate permissions and policy at the downstream execution point rather than trusting the model's decision.
8. Record and evaluate. Preserve required evidence, measure the result, capture human decisions, and feed reviewed outcomes into improvement.

EAINE — Context Contract Runtime Sequence · EAINE original AI-assisted architecture illustration

The contract should be short-lived. Identity, policy, workflow state, and source freshness can change. A contract generated at the beginning of a long-running agent workflow should not remain valid indefinitely.

Example: resolving a customer credit request

Suppose a service employee asks an AI assistant to resolve a credit request after repeated delivery failures.

Without a context contract, the assistant may retrieve general refund policy, summarize the complaint, and recommend a credit. It might appear useful while missing a regional exception, the employee's approval limit, or an earlier credit already issued.

With a context contract, the runtime boundary becomes explicit:

The model can still make mistakes. The important change is that its knowledge and authority are bounded, visible, testable, and independently enforced.

Design principles for enterprise teams

Make the contract declarative

Define the boundary as structured policy and typed fields rather than distributing it across prose prompts and application branches. A declarative contract is easier to review, version, test, and compare across use cases.

Keep policy outside the model

The model can interpret a situation and propose an action. It should not be the final enforcement point for identity, authorization, segregation of duties, or transactional controls.

Treat missing context as a valid outcome

The system should be allowed to say that it cannot proceed because required evidence, authority, or approval is missing. This is often safer and more useful than forcing a confident answer from incomplete context.

Separate evidence from instructions

Retrieved documents, emails, webpages, and tool output may contain untrusted text. Architectures should preserve the distinction between system policy, user intent, enterprise evidence, and external content throughout the interaction.

Bind actions to evidence

A high-impact action should reference the evidence and policy that justify it. If the underlying context changes, the action authorization should be re-evaluated.

Evaluate the contract, not only the model

Test whether the system selected the correct sources, excluded prohibited data, detected conflicts, applied the correct policy, enforced action limits, escalated appropriately, and preserved provenance. A correct answer produced through an invalid boundary is still a system failure.

What teams should build first

Enterprises do not need a universal context-contract platform before they begin.

Start with one consequential workflow and document five things:

1. the minimum evidence needed for an appropriate decision;
2. the sources that are authoritative for each evidence type;
3. the identity and purpose rules governing access;
4. the actions the AI may propose, draft, or execute;
5. the events that require human approval or escalation.

Convert those decisions into a small versioned schema. Enforce the action boundary in downstream systems. Log the contract identifier with every output and action. Then test stale data, conflicting records, injected instructions, missing evidence, changed permissions, and ambiguous intent.

The value will not come from making the contract large. It will come from making it explicit.

The architectural shift

Enterprise AI is often described as a model connected to data and tools.

That description misses the boundary that makes those connections legitimate.

The context contract provides that boundary. It determines what the system may know, what it may trust, what it may do, and what it must prove afterward. It translates governance from policy documents into runtime architecture.

This is the deeper shift from model-centric AI to context-aware intelligence.

The enterprise system does not simply give a model more context.

It gives the model the right context, under the right authority, for the right purpose—and no more.