Years ago I worked on a product where a large customer had accumulated tens of thousands of firewall rules. Nobody could say what most of them did. Nobody dared remove one. Every rule had been correct the day it was written, and the organization evolved around it.
AI agents are recreating that situation at a hundred times the speed. A policy that governs what an agent can do is written once, against a guess about how people will work. Then the team hires more people, a new product launches, a tool nobody paid attention to becomes the one everyone uses, and the policy falls behind. Too loose in the places that matter and too tight in the places that annoy people.
That’s the problem we’ve been working on at Dtwo. This post is the design we are building toward. It is a high-level view, not a product walkthrough, and it has three parts. I will build the picture up one part at a time.
The Workforce Loop
This loop runs all day. People hand work to agents. Claude Cowork, ChatGPT, Grok, whatever your teams use. Every call an agent makes passes through Dtwo, which decides whether the action is allowed, denied, or changed, and the person gets a governed result.
The interesting part is what the loop produces along the way. Every decision leaves a record: which person, which agent, which tool, allowed or denied, and why. On its own that record is an audit trail. In the next loop it is what the policy learns from.
The Policy Loop
This loop runs on a schedule, and InfoSec or IT owns it. A policy agent wakes up, daily or weekly, and reads three things: the goals you have written down, the current policy, and what the workforce loop recorded. It then proposes a revision. A person accepts it, rejects it, or accepts a part of it. What gets accepted becomes the new policy version and goes live. Nothing is deployed without that human review.
The policy agent is yours. It can be Claude, Grok, ChatGPT, Gemini, or something you built, and it runs where you run it. Dtwo supplies the goals and the usage data, not the agent.
You do not tell the agent what to change. You tell it what you want to be true. A goal reads like a sentence an InfoSec lead would write: “Reduce every user’s permissions to the minimum their day-to-day work needs.” or “Keep the Slack policy inside the attached data classification standard.” You can attach the documents that matter, your own security standards, a compliance control mapping, and the agent reads them alongside the policy. A rule says what to do. A goal says what good looks like, and the agent does the work of getting the policy closer to it, one reviewed step at a time.
A proposal is a diff with a reason. The agent says what it wants to change and shows the evidence: nobody in the finance group has called this tool in sixty days, or three people are the only ones who ever use this write action, so scope it to them. You review the change and the evidence side by side. Accepting part of it is normal. The next run starts from this new baseline.
Unused does not mean unneeded. Thirty days of history will not show quarter-end work or the thing the on-call person does twice a year. So when a tool looks unused, the refined policy does not remove it. It puts the tool behind a Dynamic Safeguards confirmation instead. The person confirms and keeps working. Each confirmation is recorded, so the next refinement knows not to overtighten that tool again. Tightening is cheap to undo because the people doing the work undo it for you, in the moment, without a ticket.
The loop has one optional step. When a refinement works, you can offer it to our open source policy catalog, stripped of anything specific to you. Other customers’ agents pick it up, refine it against their own usage, and share it back. Sharing is opt-in, goal by goal.
Context and Triggers
The scheduled loop handles drift. It does not handle Tuesday afternoon, when a CVE lands for a binary your developers’ agents call a hundred times a day.
That is the third part. Real-time signals feed straight into Dtwo and tighten or widen a policy the moment they arrive, inside limits you set in advance. A new CVE on a bash binary moves that tool into a tighter control mode until someone clears it. An alert from your intrusion detection locks down internal tools for the workforce while the incident is open. Identity and device signals, threat intel, and change windows fit the same shape. The signals also reach the policy agent, so the next proposal knows what happened.
The Big Picture
Two loops at different speeds with different owners, and real-time signals on top. Dtwo sits in all three, which is what lets a decision made in the policy loop take effect in the workforce loop, and an outside event can tighten both loops in the same minute.
What You Get
Least privilege that tracks reality instead of the org chart from the day you set it up. Tightening that does not lock people out, because a confirmation step replaces a hard deny. A review queue with evidence attached, so the person accepting a change can see why. A version history, so any change can be rolled back. A response to a CVE or an incident measured in minutes, with no one hand-editing a policy under pressure. And a policy set that gets better with use, which is the opposite of what policy sets usually do.
Good policy unlocks AI adoption. Policy that keeps up is how it stays unlocked.
Want to see what your agents are actually doing today? Start a free trial.
FAQ
What is an adaptive policy? A policy that changes over time based on telemetry: what people and their agents actually do, which rules fire and which never do, and real-time signals such as a new CVE or an intrusion alert. The changes are proposed by a policy agent and accepted by a person. The policy does not rewrite itself.
Does an adaptive policy mean the AI changes my security rules on its own? No. Policy agents propose. A person in InfoSec or IT accepts, rejects, or accepts part of each proposal, and every accepted change is a new version you can roll back. Real-time triggers can tighten a policy immediately, but only within the bounds you set in advance.
What stops an adaptive policy from locking people out of tools they rarely use? Absence of use is not absence of need. Instead of removing a rarely used tool outright, the refined policy puts it behind a confirmation step. The person confirms and keeps working, and that confirmation is a signal to the next refinement that the tool is still needed.