Good policy is the hard part. So we're sharing ours.

Securing each system isn’t enough

You can harden every system an AI agent touches — Salesforce, Box, Outlook, OneDrive, ServiceNow — and still lose. An agent doesn’t work inside a single system; it moves between them, and the risk lives in that space. What guards the ground between systems isn’t any one of those controls. It’s policy: the rules for what an agent may and may not do.

Good policy is genuinely hard to write — hard enough that no one should have to do it alone. So we’re building a community where security practitioners and the subject-matter experts who know these apps write and share effective policies, out in the open.

The risk isn’t a single system

Take a customer-churn report. You ask an agent to build one. It pulls account and opportunity data from Salesforce — fine, that’s its job. To enrich the accounts with churn signals Salesforce doesn’t hold, it sends the raw customer list to a third-party data service. From each system’s point of view, that’s also fine. Two systems, two permitted actions, one data breach.

A single read is fine. A single send is fine. The combination is the incident. Strong identity and authentication don’t stop it. They confirm which agent acted, not whether reading customer data and shipping it to an outside tool without first masking the sensitive fields should ever happen together. (More on why authorization, not audit, is the pillar that has to carry this.)

Policy is the containment

The whole trick is containing that without breaking the agent. Lock it down too hard and it can’t do the job you deployed it for; leave it too open and you get the churn-report incident. Good policy is the narrow band in between: enough constraint that the agent can’t do real damage, enough room that it still delivers. That’s the idea behind intent-based policy — state the outcome you want, and let the agent do everything that doesn’t cross it.

Why good policy is hard

Writing a good policy for Salesforce means knowing the business process the agent is automating and the Salesforce application and API well enough to tell a routine call from a dangerous one. That knowledge usually lives with the person who runs Salesforce — the application SME — not the security team. Security owns the risk; the SME owns the context. Good policy needs both, and in most organizations they sit in different rooms.

We’re all governing the same apps

But we’re mostly governing the same handful of tier-1 apps. Your Salesforce agent and mine face the same risky operations — exporting the full contact list, changing a closed deal, reading a restricted field. If someone has already written and vetted a good policy for that, why should everyone write it from scratch?

So we’re sharing ours — as a running start, not a finished answer. You take a policy that already exists and adapt it to your own app configuration and risk tolerance, instead of writing it from a blank slate. The risky operations are the same for everyone; the exact thresholds stay yours to set.

“Doesn’t publishing your policies hand attackers a map of what’s blocked?” No — for the same reason CIS Benchmarks, Sigma detection rules, and OPA policy libraries are all public. These are best-practice controls for common apps, not any one company’s secrets, and “they didn’t know it was blocked” was never a real defense. Policy that’s shared and reviewed in the open is stronger policy.

The policy store

We created policy-store: an open-source repository of agent policies for common apps and use cases, browsable by app, industry, and bundle. DTwo can pull policies straight from it, so adopting one is a step, not a project.

Over time we hope customers and application SMEs contribute the policies they’ve written — the people closest to each app, sharing what “safe” looks like for it, so the library gets better for everyone running the same stack.

The faster good policy spreads, the faster all of us can put agents to work without giving up control. Good policy unlocks AI adoption.