Intent-Based Policies for AI

Organizations want to describe AI policy in plain language — the way regulation, board policy, and customer commitments are already written — and today they can’t. AI is in the workflow of most knowledge and frontline workers with or without formal adoption, and the controls security teams have in place were designed for a human using a known application.

These controls break in the most consequential way exactly when an agent composes actions across them in a single request — where incidents are most likely to start and least likely to be caught.

This post summarizes our executive brief on intent-based policies: the model we believe closes that gap. State policy as the outcome, in the language regulation already uses. Evaluate against that outcome directly. Deploy learning-first, not enforce-everything-day-one.

Visible or invisible — that’s the real choice

The choice is not between using AI or not. It is between visible and invisible use.

AI is in use inside most organizations regardless of whether IT has formally approved it. Employees routinely paste internal data into models the organization has no contract with, no audit relationship with, and no ability to revoke. Banning external AI does not reduce AI use — it pushes it underground.

The realistic posture is to assume the workforce will use AI, and to make the sanctioned path the easiest path: provisioned models, vetted agents, approved MCP servers, predictable identity and audit, and a policy layer rich enough that “yes, but with constraints” is the default outcome rather than “no.”

The gap: four layers, two of them ungoverned

Most organizations already operate an identity and access management program — IdP, gateways, SaaS admin consoles, DLP, SIEM. A single user request to an agent can produce decision points at four layers:

1. The agent — plans and reasoning
2. The MCP server — tool integrations
3. The API behind the tool — gateway, scopes
4. The system or data store — DLP, RBAC, audit

APIs and data stores are already governed — separately, in different languages, by different teams. Agents and MCP servers typically have no organizational controls today. Both are now in the call path of every agent-mediated action.

Why current controls fall short

Identity is fragmented. Every governable action happens at the direction of at least one identity — a user, an agent, or a service identity. For policy to function and audit to be traceable, each has to be clearly identifiable on every call. In most stacks today they are not: the same actor can present materially different identities to different downstream systems on the same call path.

Per-system rules miss the failures unique to agents. Cross-system composition (a single read is fine, a single send is fine — the combination is the incident); sequence patterns (small individually-permitted actions amounting to bulk export when looked at as a session); goal-shaped reasoning that is impossible to write as a parameter check.

Agents work around controls. Not from malice, but from the property that makes them useful. A well-meaning agent does not understand the organizational reason a path is closed; it reads each closed door as a problem to be solved on the way to the user’s stated goal. That converts every gap between controls into an attack surface.

Security controls aren’t missing. They were built for humans, not agents.

What changes with intent-based policy

The structural mismatch is that policy describes outcomes — don’t expose customer data, don’t take destructive actions in production without approval, don’t reach across tenants — while enforcement happens in mechanics: block calls to specific endpoints, allowlist tool names, deny payloads above a size threshold. Translating one into the other is manual, error-prone, and goes stale every time the surface beneath it changes.

Two facts make the case for closing the gap now: regulation is already written as intent (GDPR, HIPAA, PCI-DSS, SOC 2, and the emerging AI-specific regimes describe outcomes, not API calls), and intent is the only level of description that survives the surface changing. Tool names, vendors, and APIs will change; the statement don’t exfiltrate customer data will not.

A few properties of the model:

• Multiple actors hold intent. The organization (law, regulation, corporate policy), the admin (operational rules), the user (session goals plus standing rules — like “don’t read emails older than a year”), the agent (its plan), and the resource itself (per-access conditions evaluated against the record’s current state).
• Intent comes in two forms. Declared intent is authored by humans and version-controlled; runtime intent is read from the session as it unfolds. Declared has higher trust and precedence; runtime has to be cross-checked against actual behavior.
• Outcomes are a dial, not a switch. Each intent sits somewhere from open (logged, not gated) through notify-and-log, confirm, to closed (blocked). A mature deployment has a portfolio of intents at different positions, with the dial reversible.
• It augments the existing stack. Identity, rule-based gateways, DLP, and SIEM still do their jobs underneath. Intent-based policy is a layer above — addressing the ambiguous middle ground that mechanical rules cannot reach.

Anatomy of intent

Outer layers set the limits; the data adds its own. Admin intent constrains user intent, which constrains agent intent — and in parallel, every action is checked against the conditions the data owner set on the specific record being touched (classification, regional residency right now, care-team membership, retention and legal hold), no matter who is acting.

A user cannot override admin policy, and an agent cannot override the user’s goals — and the system has to enforce that actively, not assume it holds. The failure modes the model must catch — insider misuse, agent off-task, and resource breach — are exactly the gaps agents most readily find when one of these checks is missed.

Every governed action lands in a structured audit record with six parts: principal (who the work is for), actor (the agent or service identity, with model and tool versions), session (the chain of calls that produced the action), action (the operation and the path it took), resources (records touched, with their resource-intent at the time), and decision (mode, intent matched, evaluator reasoning).

A path, not a switch

Intent-based policy is desirable — the kind of clean, durable framing CISOs would adopt tomorrow if it were available as a complete product. It is not yet that, and we think honesty here matters.

The mechanisms are practical today and deliver value as soon as they are deployed: declared and runtime intent, the mode dial, observation-mode rollout, the supervision loop, a starter library of common intents. The full vision — intent statements that hold up under adversarial pressure, evaluators that match a thoughtful human at judging fuzzy cases — depends on AI capabilities that are still improving and on changes to the surrounding software that are already underway.

The path is incremental. The mechanisms work today for the cases they cover; cases beyond their current reach fall back to the rule-based controls beneath. Each generation of model improvement extends what the system can be trusted to handle.

Where to start

1. Inventory current AI use, sanctioned and shadow. You can’t govern what you can’t see, and the inventory itself surfaces the highest-leverage targets for everything that follows.
2. Identify your top 3–5 high-risk intents. You probably already have them on file — don’t exfiltrate customer data, don’t take destructive action in production without approval, don’t reach across tenants.
3. Decide where intent authorship lives. You need one owner — security, GRC, platform engineering, or the AI program. The hand-off between policy author and engineering implementer is the failure mode you are trying to remove.
4. Pilot in observation mode against a single role. Capture decisions; do not enforce. The observation data is what tells you whether your intents are right before they affect anyone.
5. Plan the audit schema before enforcement. Principal, actor, session, decision — landing in the same SIEM your existing audit lands in. Retrofitting an audit schema is more painful than getting it right the first time.

Say “yes, with constraints” — and mean it

AI usage inside the enterprise will continue to grow. The choice is not between adopting AI and avoiding it; it is between an environment where AI use is invisible and one where it operates within enforceable guardrails — guardrails that express what the organization actually means.

The organizations that get ahead of it will be the ones that say yes, with constraints to their workforce’s AI use — capturing the value their people are already reaching for, without the exposure that comes when AI runs unobserved — and mean it.

Want the full whitepaper, or to talk through what this looks like in your stack? Reach us at connect@dtwo.ai.