Why Deploy Layer 1 First
Layer 1 — the Corporate Constitution — provides the highest-impact governance improvement with the lowest implementation complexity.
- Without Layer 1: Every AI session starts from zero. The AI has no organizational identity, no regulatory awareness, no data classification framework, and no basis for refusing inappropriate requests.
- With Layer 1: Every AI session starts with identity, authority limits, data handling rules, and behavioral mandates already loaded — even if Layers 2 and 3 are never implemented.
Layer 1 alone transforms AI from "general-purpose tool an employee happens to use at work" to "organizational participant operating within defined boundaries."
Deployment Methods
Enterprise AI tools fall into four categories based on how they accept constitutional instructions:
| Category | Mechanism | Deployment Method |
|---|---|---|
| File-based | Instruction files in repos or on endpoints | Deploy constitution as a managed file |
| API-level | System prompt parameter in API calls | Inject constitution server-side in application code |
| Builder UI | Agent/assistant configuration interfaces | Paste constitution into instructions field |
| Policy-layer | Guardrails, trust layers, governance gateways | Encode constitutional rules as platform policies |
Most organizations use tools across multiple categories. The constitution content is the same — only the delivery mechanism changes.
Token Budget Considerations
AI models have finite context windows. The constitution consumes tokens from that budget:
| Constitution type | Approximate tokens |
|---|---|
| Corporate only (minimal) | 800 - 1,200 |
| Corporate only (full) | 1,500 - 2,500 |
| Corporate + Team | 2,000 - 3,500 |
| Corporate + Team + Practitioner | 2,500 - 4,500 |
The Constitution Builder tracks token count in real time as you fill in each section, so you can stay within your deployment target's limits.
AI Coding Agents
These tools operate in developer environments. Layer 1 is deployed as managed instruction files on endpoints or in repositories.
| File | CLAUDE.md (project root) for project-level; ~/.claude/CLAUDE.md for user-level |
| Enterprise lock | managed-settings.json deployed at OS level |
| Lock file paths | Linux: /etc/claude-code/managed-settings.jsonmacOS: /Library/Application Support/ClaudeCode/managed-settings.json |
| Drop-in directory | managed-settings.d/*.json for modular policy deployment |
| Deployment tools | MDM (Intune, JAMF), configuration management (Ansible, Chef, Puppet) |
| Hierarchy | Server-managed > OS-level managed-settings > user settings > project settings |
| Layer 1 approach | Deploy the corporate constitution as a managed CLAUDE.md at the enterprise level via MDM. Use managed-settings.json to enforce behavioral policies. The constitution text goes in CLAUDE.md; the enforcement rules go in managed-settings. |
- Author the corporate constitution using the Builder
- Deploy to all managed endpoints via MDM or configuration management
- Lock file permissions so users cannot modify
- Use
managed-settings.jsonto enforce tool-level restrictions that complement the constitution
| File | .github/copilot-instructions.md (repo root) |
| Granular files | .github/instructions/**/*.instructions.md |
| Enterprise lock | Enterprise-level policies in GitHub Enterprise Cloud admin; cascade: Enterprise > Organization > Repo > Personal |
| Layer 1 approach | Set organization-level instructions in the GitHub Enterprise admin console. These apply to all repos and cannot be overridden. Supplement with repo-level files for Layer 2. |
- Adapt the corporate constitution for Copilot's instruction format
- Deploy organization-level instructions via GitHub Enterprise Cloud admin
- Enforce at enterprise level so org admins cannot relax the policy
- Use repo-level
copilot-instructions.mdfor Layer 2 context only
| File | .cursor/rules/*.md (project-level rules with glob matching) |
| Enterprise lock | Business/Enterprise dashboard distributes team-wide rules via deeplinks |
| Admin controls | SSO (SAML), SCIM, RBAC, MDM policies; admins control model access, MCP servers, extensions |
| Layer 1 approach | Define the corporate constitution as team-wide rules in the Cursor Enterprise dashboard. Auto-distributes to all team members. Per-project .cursor/rules/ files serve as Layer 2. |
- Author constitutional rules in the Cursor Enterprise admin dashboard
- Distribute to all seats via centralized team rules
- Use project-level
.cursor/rules/*.mdfor team-specific context
| File | .windsurf/rules/*.md (project-level) |
| Enterprise lock | System-level workflows deployed to OS-specific directories (read-only) |
| Lock paths | macOS: /Library/Application Support/Windsurf/workflows/*.md; deployable via MDM |
| Layer 1 approach | Deploy the corporate constitution as a system-level workflow file via MDM. Read-only. Project-level files serve as Layer 2. |
| File | .amazonq/rules/*.md (project root) |
| Enterprise lock | AWS Organizations SCPs control feature availability org-wide |
| Layer 1 approach | Use SCPs in AWS Organizations to enforce baseline AI governance. Deploy customizations centrally via AWS console. Supplement with repo-level rules for project context. |
| File | .gemini/styleguide.md (repo root) |
| Enterprise lock | Group-level style guides in Google Cloud console (Enterprise tier) |
| Layer 1 approach | Define the corporate constitution as a group-level style guide via Google Cloud console. Repo-level files are merged with (not override) the group guide. |
| File | .aiassistant/rules/*.md (project root) |
| Enterprise lock | JetBrains IDE Services manages AI profiles centrally |
| Layer 1 approach | Deploy centrally managed AI profiles with constitutional language via IDE Services. Supplement with project-level rules files for Layer 2. |
| File | /.tabnine/guidelines/*.md (per-project) or ~/.tabnine/guidelines/*.md (global) |
| Enterprise lock | Admin UI > Agent Guidelines; admin guidelines override personal files |
| Layer 1 approach | Deploy the corporate constitution as organization-wide guidelines in the Tabnine Admin UI. These take precedence over all user-level guidelines. |
| File | AGENTS.md (repository root) |
| Supported by | GitHub Copilot, Cursor, Windsurf, OpenAI Codex, Zed, Aider, Semgrep, Warp, Factory |
| Governed by | Agentic AI Foundation (Linux Foundation) |
| Layer 1 approach | Deploy an AGENTS.md containing the corporate constitution at the root of every repo. Tool-agnostic baseline. Best used as a complement to tool-specific mechanisms — has no enterprise lock since it lives in the repo. |
Enterprise Chat & Assistant Platforms
These platforms serve non-developer employees through conversational interfaces. Layer 1 is deployed through admin consoles, API configurations, or agent builder UIs.
| Prompt mechanism | Declarative Agent instructions in Copilot Studio |
| Enterprise lock | Copilot Control System (CCS) + Agent 365 unified control plane; Entra ID governance |
| Layer 1 approach | Create a base Declarative Agent in Copilot Studio whose instructions contain the constitution. Use CCS policies to enforce organizational boundaries. All custom agents inherit organizational policies. |
| Prompt mechanism | Custom GPTs with natural-language instructions; API developer messages |
| Enterprise lock | Domain allowlists, sharing scope restrictions, group permissions |
| Layer 1 approach | Create an org-standard Custom GPT whose instructions contain the constitution. Restrict the workspace so employees use it by default. For API: inject as the developer message server-side. |
Limitation: OpenAI does not currently support forcing all users to use a specific GPT. Users can create personal GPTs that lack constitutional instructions. Mitigate via policy + monitoring.
| Prompt mechanism | Admin Console toggles per OU; Vertex AI Agent Builder for custom agents |
| Enterprise lock | Google Admin Console, DLP policies, IAM |
| Layer 1 approach | Control Gemini access per OU in Admin Console. Build custom agents in Vertex AI Agent Builder with constitutional instructions. Model Armor enforces prompt injection protection at the platform level. |
| Prompt mechanism | System prompts set server-side via API; agent instructions in Bedrock console |
| Enterprise lock | IAM-enforced mandatory guardrails; AWS Organizations Bedrock Policies |
| Layer 1 approach | Create Bedrock Guardrails encoding the constitutional rules. Enforce via IAM policies so they apply to every inference call across the organization. System prompts are set server-side and never exposed to end users. |
This is the strongest centralized enforcement model among the platforms listed. Guardrails are deterministic and IAM-enforced.
| Prompt mechanism | Projects with custom instructions on claude.ai; API system parameter |
| Enterprise lock | Managed policy settings; Compliance API for monitoring |
| Layer 1 approach | Create organization-standard Projects with constitutional instructions. For API: inject as the system parameter. For Claude Code: deploy via managed-settings and managed CLAUDE.md. Use Compliance API for monitoring. |
| Prompt mechanism | Agent instructions + Agent Script (deterministic guardrails) |
| Enterprise lock | Einstein Trust Layer; agents inherit Salesforce user permission model |
| Layer 1 approach | Encode constitutional behavioral rules as Agent Script constraints (deterministic, not probabilistic). Set organizational identity in agent instructions. Einstein Trust Layer enforces PII masking, toxicity detection, and audit trails. |
| Prompt mechanism | Workflow-embedded agent configurations |
| Enterprise lock | AI Control Tower — cross-platform governance |
| Layer 1 approach | Embed constitutional rules in ServiceNow agent configurations. AI Control Tower can discover and manage agents from ServiceNow, Microsoft, and other platforms — potential single pane of glass for Layer 1 enforcement. |
| Prompt mechanism | Versioned prompt templates in watsonx.ai Prompt Lab |
| Enterprise lock | watsonx.governance — dedicated governance product |
| Layer 1 approach | Author the constitution as a versioned prompt template. Use watsonx.governance for lifecycle management and compliance monitoring. Agent monitoring tracks behaviors against constitutional rules in real time. |
| Prompt mechanism | "Preamble" system prompt via API; safety mode settings |
| Enterprise lock | North platform with built-in security and compliance |
| Layer 1 approach | Set the constitution as the preamble in all API calls. Controlled server-side — end users never see or modify it. Supports private cloud and on-premises deployment for data sovereignty. |
Agent Orchestration Frameworks
Used by development teams building custom AI applications. Layer 1 is injected at the application layer or enforced by platform governance features.
- LangChain / LangSmith — Publish as a versioned prompt template in LangChain Hub. LangSmith Fleet provides the centralized registry.
- Amazon Bedrock AgentCore — Encode as Cedar policies. The Gateway enforces every tool call deterministically before execution. Framework-agnostic.
- Google Vertex AI Agent Builder — Set constitutional system instructions. Use IAM to scope agent identities as first-class principals.
- Microsoft Agent Framework — Deploy via Azure governance controls. Prompt shields protect against injection. Purview integration for compliance.
- Databricks / Mosaic AI — Unity Catalog for unified governance. Mosaic AI Gateway provides the centralized entry point with rate limiting and permissions.
- Snowflake Cortex — Agent instructions via Cortex APIs. AI Governance Gateway enforces access control. All processing stays within Snowflake's security perimeter.
- Palantir AIP — The strongest ontological governance model. Constitutional rules embedded in the platform's security model. Supports air-gapped environments.
Cross-Platform Deployment Strategy
For organizations using multiple AI tools, deploy Layer 1 in priority tiers:
Tier A — Immediate (highest impact, lowest effort)
These mechanisms lock the constitution at the platform level. Users cannot bypass them.
- Claude Code — Deploy
managed-settings.json+ managedCLAUDE.mdvia MDM - Amazon Bedrock — IAM-enforced guardrails via AWS Organizations
- Tabnine — Admin guidelines in the Admin UI (override user-level)
- GitHub Copilot — Enterprise-level policies in admin console
Tier B — Standard (requires admin console configuration)
- Microsoft Copilot — Copilot Control System policies + Declarative Agent instructions
- ChatGPT Enterprise — Corporate Custom GPT + workspace restrictions
- Cursor — Enterprise dashboard team-wide rules
- Salesforce Agentforce — Agent Script + Einstein Trust Layer
- Windsurf — OS-level system workflows via MDM
Tier C — Application-layer (requires development work)
- Any API-based deployment — Inject constitution as system/developer message server-side
- LangChain/LangSmith — Publish as versioned Hub template
- Custom internal platforms — Embed in prompt management layer
Tier D — Supplementary (defense in depth)
- AGENTS.md — Commit to all repos; protect via branch rules
- Repo-level instruction files — For Layer 2 context; not a substitute for enterprise enforcement
- ServiceNow AI Control Tower — Cross-platform governance overlay
Adapting for Different Platforms
Token / length constraints
If a platform constrains system prompt length, prioritize in this order:
- Sections 01 (Identity) and 02 (Organizational Context) — the constitutional foundation
- Sections 04 (Data Classification) and 05 (Behavioral Mandates) — the enforcement core
- Sections 06-08 (Misuse, Refusal, Scope) — can be condensed
Platform-specific formatting
- API-based: Plain text or Markdown in the system message
- File-based: Markdown files
- Builder UIs: Paste into the instructions field
- Policy engines: Translate behavioral rules into platform-native policy syntax
What stays constant across all platforms
- Organizational identity — Who the AI works for
- Regulatory context — What frameworks govern the work
- Authority hierarchy — This constitution overrides all other instructions
- Data classification — How to handle information at different sensitivity levels
- Behavioral baseline — Non-negotiable rules for every session
Verification
After deploying Layer 1 to any platform, validate using the test suite:
- Identity test: Ask the AI "Who do you work for?" — it should name the organization
- Authority test: Attempt to override a constitutional rule — the AI should refuse
- Regulatory awareness test: Present a regulatory scenario — the AI should flag compliance implications
- Data classification test: Present information at various levels — the AI should apply correct handling rules
Troubleshooting
Users report the AI is "too restrictive"
- Review refusal logs for false positives
- Check if data classification tiers are too aggressive for the team's actual work
- Consider adding a team-level constitution that clarifies approved workflows
Users report the AI "doesn't know who it is"
- Verify the constitution is actually being loaded (check system prompt, file path, MDM deployment)
- Test with TC-01 (identity check) from the test suite
- Check for token truncation — if the constitution exceeds the limit, it may be silently truncated
Prompt injection tests fail
- Verify the injection detection language in Section 06 is present and not truncated
- Test with simpler injection attempts first
- Consider strengthening the injection detection language or adding examples
This guide covers platforms as of March 2026. The enterprise AI governance landscape is evolving rapidly. Review platform capabilities quarterly and update deployment mechanisms as platforms add new governance features.