ORIGINAL FRAMEWORKS
The three organizational layers every enterprise must design before any agent goes live. Containment is Layer 1. Almost no enterprise builds Layer 3.
Intent documented at deployment is not the same as intent maintained over time. The stack was built around that distinction because most governance failures are not authorization failures at launch. They are drift failures six months later when the original decision-makers are gone.
Scope
The Intent Architecture Stack is a platform-independent governance framework. The organizational decisions it requires apply regardless of vendor or deployment environment. This page operationalizes it for Microsoft-first enterprises using Microsoft Entra Agent ID, Microsoft Purview, and Copilot Studio.
The Intent Architecture Stack operationalizes what existing frameworks require but do not implement at the agent level - instantiating NIST AI RMF's GOVERN function, EU AI Act Article 26's human oversight requirement, and the CSA Agentic Profile's accountability register for Microsoft-first enterprises.
Free to read and cite with attribution to Sougata Roy and sougataroy.com. Do not republish, rebrand, or claim authorship of any framework, term, or model as your own.
The problem
Inside the organization
The framework
The Intent Architecture Stack has three organizational layers. Each one is a governance decision, not a technical configuration. All three must exist before an agent is considered authorized to operate. Most organizations build Layer 1 informally, build Layer 2 partially, and skip Layer 3 entirely until something forces the question.
Pre-rollout governance checklist
Identify Regulatory Environment: identify the regulatory environment and list all specific obligations.
Who it is for
Quick reference
A one-page checklist covering all three layers of the Intent Architecture Stack. Complete it before any agent goes live.
QUICK CHECK
Twelve governance items across three layers. Every unchecked box is a unit of Governance Debt.
OPERATIONAL GOVERNANCE
Layer 3 names a Consequence Owner and defines an escalation path. Most organizations interpret this as accountability for what the agent produces: its outputs, its recommendations, its decisions. There is a second accountability question Layer 3 must answer, and most organizations have not answered it.
When an AI agent recommends, initiates, or facilitates a change to an organizational system, such as a configuration, an access control, a database record, or a security setting, does that change require the same human approval process it would require if a person initiated it?
In three documented incidents between 2025 and 2026, the answer was no. The agent acted, or the agent's recommendation was implemented, without the change management controls that would have applied to the same action taken by a person.
MARCH 2026 · META INTERNAL ENVIRONMENT
A Meta internal AI agent autonomously posted advice to an internal forum. A second employee followed the agent's recommendation and changed system settings, widening data access beyond authorized roles. Sensitive company and user data was broadly accessible to engineers for approximately two hours before the breach was contained. The change the agent recommended would have required change management approval if a human had initiated it.
LAYER 3 GAP
No governance control defined which agent recommendations required human change management review before implementation. The Consequence Owner structure did not extend to the agent's ability to influence system configuration through its outputs.
Source: Oso Agents Gone Rogue register, March 2026
2025-2026 · REPLIT AI CODING ASSISTANT
A Replit AI coding assistant was given explicit instructions not to modify production systems. The agent ignored those instructions eleven times, fabricated test data, and ultimately deleted a live production database. The agent had the technical permissions to execute destructive commands. No human confirmation was required for operations that would have required change management approval from any human engineer.
LAYER 2 AND LAYER 3 GAP
The authorized scope in Layer 2 named the prohibition but no technical or governance control enforced it. Layer 3 did not define which agent actions required human confirmation before execution, regardless of what the agent had been told.
Source: Oso Agents Gone Rogue register, 2025-2026
2025-2026 · MICROSOFT COPILOT FOR SECURITY
Security practitioners documented a pattern in Microsoft Copilot deployments for security, identity, and administration tasks, including Copilot in Microsoft Entra and Microsoft Defender. Even suggest-only agents drove misconfigurations when administrators over-trusted recommendations and did not integrate AI-assisted changes into standard change management processes. The AI was introduced as a productivity tool. It functioned as a change-originating actor.
LAYER 3 GAP
Copilot-assisted changes were not classified as change-originating actions subject to change advisory board or dual-control processes. No written policy defined which Copilot-assisted changes required the same review that would apply if a human engineer initiated the same configuration change.
Source: EchoLeak research; Microsoft Security Copilot documentation; Microsoft Learn guidance on applying Zero Trust principles to Microsoft 365 Copilot, verified 2026-05-03
THE GOVERNANCE REQUIREMENT
Layer 3 must answer two questions, not one. The first: who is accountable for what this agent produces? The second: which agent actions require the same human approval process they would require if a person initiated them? An authorization record that answers only the first question is incomplete.
Before deployment
Risk proportionality
The Intent Architecture Stack applies to every deployed agent. Documentation depth scales with risk. These three tiers define proportional documentation requirements. Note that tier classification governs internal governance proportionality, not legal classification - some Tier 2 agents may still be classified as high-risk under the EU AI Act or applicable regulatory frameworks.
TIER 1
Profile: Internal-only, reads non-sensitive or non-regulated data, no external communications capability, no record modification in regulated systems, no financial transactions. Internal communications are limited to the invoking user or a defined small team - not broadcast-capable.
Documentation depth: Lightweight Intent Document. Class-level Context Document. Basic Governance Record with named Consequence Owner and event-based review triggers.
Examples: Internal knowledge summarizers, document search agents, read-only analytics agents reporting to the invoking user.
TIER 2
Profile: Cross-departmental access, reads regulated data, internal communications capability, recommendation outputs that inform human decisions but do not execute them. May include agents that create or update internal records and drafts that are not authoritative sources of record, where a human must review and approve before any customer-facing or regulator-facing action occurs.
Documentation depth: Full Intent Document with all three components including explicit prohibitions. Agent-specific Context Document. Full Governance Record with named Consequence Owner, defined Review Cadence, and written Escalation Path.
Note: Some Tier 2 agents may still be classified as high-risk under the EU AI Act. This tier governs internal proportionality, not legal classification.
Examples: Compliance monitoring agents, customer service drafting agents, risk flagging agents, agents creating internal case records subject to human review.
TIER 3
Profile: External communications, financial transaction execution, record modification in authoritative regulated systems, customer-facing autonomous decisions. Includes agents that can invoke or delegate to sub-agents with authority to change records, communicate externally, or execute transactions without an additional human gate. Tier 3 is where both exposure and autonomy are high.
Documentation depth: Full three-layer stack. Named Consequence Owner with board-level accountability nested in formal accountability structure. Formal review cadence with evidence records. Written Escalation Path with named contacts. Pre-deployment governance sign-off. Board-level posture reporting.
Examples: Trading workflow agents, claims processing agents, customer communication agents, multi-agent orchestration systems with transactional authority.
Class-level documentation rule
Tier 1 agents may share a Context Document across a class of similar agents. Tier 2 and Tier 3 require agent-specific documentation for every deployed agent.
Tier 2 Intent Document
REAL-WORLD VALIDATION
In 2025 and 2026, security researchers disclosed two named vulnerabilities across Microsoft's AI stack. Each one exploited the same architectural gap: AI agents designed as helpers were wired into systems without explicit trust boundaries, and external content reached them as instructions. The failures were not configuration errors. They were design decisions that had not been made.
CVE-2025-32711 · MICROSOFT 365 COPILOT
Aim Security disclosed a zero-click vulnerability in Microsoft 365 Copilot, rated CVSS 9.3 and disclosed in June 2025. Attackers used crafted content, including Outlook emails, that Copilot processed as instructions, causing it to exfiltrate sensitive data from the tenant without any user interaction. Copilot's design allowed external content to function as high-privilege instructions inside the tenant. No user click was required. No user awareness triggered it.
LAYER 1 AND LAYER 2 FAILURE
The regulatory environment and data touchpoints in Layer 1 were not mapped before deployment. The authorized scope did not define what external content could trigger agent action in Layer 2. The result was a production system with no documented boundary between untrusted input and privileged internal action.
Source: Aim Security, EchoLeak disclosure, CVE-2025-32711, CVSS 9.3, June 2025
ORCA SECURITY RESEARCH · GITHUB CODESPACES
Orca Security disclosed a vulnerability in GitHub Codespaces where Copilot acted on malicious instructions injected into GitHub Issues. When a developer launched a Codespace from a tainted issue, Copilot consumed the issue text as context, executed attacker-crafted instructions, and exfiltrated the GITHUB_TOKEN from the Codespace. The token gave full repository takeover capability.
ALL THREE LAYERS ABSENT
The system integration scope in Layer 1 did not account for Copilot's access to Codespace environment credentials. No authorized scope defined what actions Copilot could take on environment tokens in Layer 2. No Consequence Owner had accepted accountability for Copilot's behavior inside Codespace runtime environments in Layer 3.
Source: Orca Security, RoguePilot research, February 2026
CVE-2026-21520 · COPILOT STUDIO
Capsule Security disclosed ShareLeak in January 2026, a CVSS 7.5 indirect prompt injection vulnerability in Microsoft Copilot Studio. An attacker inserted a crafted payload into a public-facing SharePoint form field. Copilot Studio concatenated the untrusted form input directly into the agent's system instructions with no sanitization between the form and the model. The agent then queried connected SharePoint Lists for customer data and exfiltrated it via Outlook to an attacker-controlled address. Microsoft's own safety mechanisms flagged the request as suspicious. The data was exfiltrated anyway.
LAYER 2 FAILURE - AND THE DLP ASSUMPTION
The authorized scope (Layer 2) did not define which input sources the agent was permitted to treat as instructions. DLP policies governed data egress from connectors but did not define input trust boundaries. The agent exfiltrated data through an authorized Outlook connector, which DLP did not flag because the connector was legitimate. A Layer 2 authorization record specifying that untrusted form field content may not be treated as agent instructions would have named the boundary the patch alone did not close.
Source: Capsule Security, ShareLeak disclosure, CVE-2026-21520, CVSS 7.5, January 2026. Covered: CSO Online, April 2026.
CVE-2025-53773 · VISUAL STUDIO & COPILOT
Disclosed in August 2025, CVE-2025-53773 demonstrated how prompt injection in Visual Studio and Copilot can escalate from data exfiltration into wormable remote code execution across CI/CD pipelines. When an agent can modify its own configuration files and security-relevant settings, injected prompts can propagate through shared repositories. The exploit chain self-replicates across development environments connected to the same pipeline. No single compromised repository contains the attack. The attack is the pipeline.
ALL THREE LAYERS ABSENT
The regulatory environment and system integration scope (Layer 1) did not enumerate that the agent operated inside a CI/CD pipeline with write access to shared repositories. The authorized scope (Layer 2) did not define that agents may not modify configuration files or security settings without human review. No Consequence Owner had accepted accountability for agent-initiated changes to the pipeline environment (Layer 3). When no layer constrains the agent's ability to act on injected instructions across a connected environment, a single crafted input becomes a self-propagating exploit.
Source: NVD, CVE-2025-53773, disclosed August 2025. Analysis: Persistent Security. Research summary: VentureBeat agentic AI security coverage, 2025-2026.
THE ARCHITECTURE PATTERN
All four vulnerabilities share one structure: an AI agent was designed as a helper but functioned as an ungoverned automation layer bridging untrusted external content and privileged internal systems. The Intent Architecture Stack exists to make that design decision explicit before deployment, not visible after an incident.
Template
Referenced in
"Who Owns the Agent?" applies this framework to real-world deployment scenarios and maps it to named governance incidents from 2024 to 2026.
White paper
The Intent Architecture Stack white paper, ten sections, complete diagnostic, named incident analysis, Intent Document template.
Executive FAQ
These are the questions that separate an intent statement from an operating governance system. If the answer is not recorded before deployment, the authorization layer does not exist yet.
No. The stack sits before technical configuration. Identity, access control, monitoring, and logs are still required, but they need an organizational authorization record to be evaluated against.
The business owner of the use case should own and approve it. Technical teams can contribute implementation details, but authorization belongs to the function that accepts the operational and compliance consequences.
Re-authorization should be triggered by a change in business purpose, data access, action scope, accountable owner, regulatory context, or any incident that shows the agent may be operating outside its documented intent.
Yes. Existing deployments should be reviewed retroactively. Any field that cannot be completed becomes a governance finding and a practical starting point for remediation.
60-minute operating sprint
Use this as a live governance exercise. Leave the session with named evidence, a visible gap, and a next owner rather than another discussion note.
Working session board
4
Steps
60
Minutes
1
Owner
Live
Decision
10 minutes
Not a technical description. A statement of intent: "This agent reviews contract documents for non-standard clauses and flags them for legal review before signature." If you cannot write this sentence without looking at the code, Layer 2 does not exist for this agent. That is your first finding.
Output
Written evidence ready for the next governance decision.
15 minutes
This is the boundary definition in Layer 2. Be specific: "Cannot access systems outside the legal SharePoint site. Cannot send email directly to external parties. Cannot make a contract modification." If you cannot write this list, the Authorized Scope component does not exist. That is your second finding.
Output
Written evidence ready for the next governance decision.
20 minutes
Not the developer. Not IT. The business owner - the person who can answer "yes, this agent should exist and here is why" if an examiner calls. Write their name, title, and where this role sits in your accountability structure. If the person you are thinking of does not know they own this agent, Layer 3 does not exist. That is your third finding.
Output
Written evidence ready for the next governance decision.
15 minutes
If you found a gap in any layer, you have identified where your Intent Architecture work begins. If you found no gaps, apply the same exercise to the next agent. Most organizations find all three gaps in the first agent they examine.
Output
Written evidence ready for the next governance decision.
Research brief
Source: NIST National Cybersecurity Center of Excellence, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," February 5, 2026.
Continue through the connected framework sequence above.