Guide
AI governance framework for enterprise delivery
AI work is entering delivery before governance has caught up. Context Stack gives teams a practical way to govern context ownership, data movement, runtime placement, and delivery authority before AI systems are given operational responsibility.
Need
The problem is not model use. The problem is unmanaged authority.
Enterprise AI governance has to answer more than whether a model is accurate. It has to decide which context the system may trust, where data may go, where AI may run, and who approves action.
Facts decay
Requirements, runbooks, decisions, tickets, chats, and handover notes drift after delivery starts.
Data moves
Prompts, embeddings, logs, vendors, APIs, and tools create data movement that normal project documents miss.
Placement matters
Cloud, on-premise, edge, and hybrid choices carry different sovereignty, control, and audit consequences.
Authority must be explicit
Models can interpret and propose. Deterministic systems must validate, authorize, execute, and log.
Method
Context Stack separates the governance questions.
The stack is split so each layer has a clear responsibility. That prevents every AI issue from becoming a generic policy discussion.
-
ContextOps
How does an organization govern AI context?
Use this for context ownership, lifecycle, freshness, maturity, practices, and accountability.
-
ContextBoundary
Where is data allowed to go?
Use this for data egress, vendor zones, jurisdictional profiles, approval paths, and audit boundaries.
-
Sthala
Where does the AI actually run?
Use this for governed AI runtime placement under ContextBoundary, runtime constraints, and approved egress boundaries.
-
Griha
How do governed AI capabilities become a running system?
Use this as a worked example of governed AI capabilities composed into a running system, with executable policy behind it.
Standards alignment
Aligned with AARM v1.0, and precise about what that means.
The Cloud Security Alliance's AARM v1.0 is the open standard for runtime agent action authorization. ContextBoundary maps to its Protocol Gateway architecture as a strict-determinism profile.
AARM-aligned strict-determinism profile — all Core requirements (R1–R6) implemented and CI-verified; independent conformance review not yet undertaken.
All Core requirements (R1–R6) are implemented and CI-verified in the reference gateway: pre-execution interception, session context, owner-declared narrowing-only intent envelopes, all five decisions including MODIFY and DEFER, tamper-evident sealed receipts, and per-agent Ed25519 identity with public-key verification. R8 OpenTelemetry export is implemented. R7 is a designed deterministic divergence — envelope-drift counting rather than semantic-distance tracking — chosen to keep any model out of the enforcement path.
Production operation and external evidence review are both prerequisites before any conformance claim, and none is made here.
The gateway is a reference implementation, verifiable from a clean clone. It is not a hosted service.
AARM specifies action authorization. It does not specify data sovereignty or vendor continuity. Those extensions — egress tiers, vendor and jurisdiction zones, audit profiles, and continuity controls — are ContextBoundary's contribution.
Standards constraints
Attribution and claim ceiling
- AARM is a Cloud Security Alliance standard, not a Context Stack standard.
- Context Stack is AARM-aligned. No conformance claim is made.
- Not listed on the CSA Builders Registry.
- No independent conformance review has been undertaken.
- Griha is a reference implementation, not a product.
Delivery
Use the framework before and during AI delivery.
The same governance questions apply across AMS, waterfall, agile, product, and platform work, but the failure mode is different in each mode.
Assess
Find the weak point: context ownership, egress control, runtime placement, approval path, or operating model.
Route
Send the problem to the right layer instead of treating it as one broad AI governance concern.
Apply
Turn the selected layer into review questions, decision records, control points, and delivery checks.
Operate
Use MCP to bring the framework into daily AI-assisted work while enforcement stays deterministic.
Access
MCP makes the framework usable inside workflow.
MCP is not the governance authority. It is the delivery access path. An assistant can consult the framework, route a question, and produce a first-pass assessment while policy enforcement remains in deterministic systems.
Start with the guided assessment
Use the homepage wizard when you need to decide which layer applies.
Use through MCP
Use the endpoint when an AI assistant needs framework guidance during delivery, review, or architecture work.
Read first
Source documents
These are the best entry points for people and AI assistants.