Tool Policies: one policy engine for every tool your AI agents call StackOne launched Tool Policies, a policy engine that governs what AI agents can do, see and send across every connector, MCP client and agent platform, down to individual fields. The company cites Gartner's prediction that by 2028 one in four enterprise breaches will be traced to AI agents misused by outside attackers or insiders, and a McKinsey 2026 survey of about 500 organizations in which nearly two-thirds named security and risk as the top barrier to scaling agentic AI. StackOne says the controls built into Claude, ChatGPT, Microsoft Copilot, Gemini Enterprise and Glean stop at the tool level and cannot, for example, let an agent pay a $250 bill while refusing a $4,800 one. Tool Policies: one policy engine for every tool your AI agents call Table of Contents Today we are launching StackOne Tool Policies https://www.stackone.com/platform/policies/ , one policy engine for every tool your AI agents call. Tool Policies set what each person’s agents can do, see and send, down to the field, across every connector, MCP client and agent platform. Why do AI agent rollouts stall at the security review? A finance team asks IT to let its agent pay supplier bills. Security looks at what the payments connector can do, which includes paying any amount to any supplier and deleting the record afterwards, and the approval is denied. In the IT and security teams we talk to, this is where most agent rollouts stop. Security teams block what they cannot govern, and it is one of the three reasons AI rollouts stall https://www.stackone.com/blog/copy-paste-economy-ai-rollouts/ that I wrote about last month. The risk is real. Gartner predicts that by 2028, one in four enterprise breaches will be traced back to AI agents misused by outside attackers or by people inside the company. In McKinsey’s 2026 survey of about 500 organizations, nearly two-thirds named security and risk as the top barrier to scaling agentic AI. Buyers tell us the same thing in their own words. An IT Director leading an internal AI rollout said they were “only tackling read only use cases” because “we’re not sure what guardrails we need.” An executive who already reads NetSuite through Claude will not let it post a journal entry until there are “more checks and balances, and security”. The controls that ship with AI platforms do not get them there. Claude, ChatGPT, Microsoft Copilot, Gemini Enterprise and Glean all let an admin decide which connectors and tools an agent can use, and most can limit that by user or group. Those controls stop at the tool. As Guillaume, our CTO, wrote in August https://www.stackone.com/blog/copilot-salary-field-agent-policies/ , the app switch “has no setting for ‘everything except salary’”, and none of the platforms can let an agent pay a $250 bill while refusing a $4,800 one. So where do you go from here? Gartner’s advice is to build these controls in before a breach, and Tool Policies let you do that today. What are StackOne Tool Policies? Tool Policies address the answers security needs before it signs off: who can do what, to what data, through which agent. Start with one rule, such as keeping customer PII out of the systems it should not reach. Scope the next one to a group, like contractors or everyone outside Finance. Then go down to a single field, or to a plain-language question like “Is this compensation?” Tool Policies sit on top of the permissions in your systems: for an employee on their own login and for a background agent on a service account alike. Nobody changes a role in the HR, CRM or finance system. Connectors open up the use cases. Doing it securely, with the right guardrails and governance in place, is what makes it possible to roll agents out across the whole business. How are Tool Policies different from the controls built into AI platforms? | Control | Built into AI platforms | StackOne Tool Policies | |---|---|---| | Turn a connector on or off | Yes | Yes | | Allow or block individual tools | Yes | Yes, by name pattern across every connector | | Scope tool access by user or group | Partly, varies by platform and plan | Yes, with groups from your identity provider | | Limit input values, such as a payment cap | No, or beta rules without numeric limits | Yes | | Mask a response field, such as salary | No | Yes | | Semantic rules on tool inputs and outputs | Prompts only, or through your own policy server | Yes, built in | | Redact PII inside tool payloads | No | Yes, on StackOne’s own model | | Test a rule before enforcing it | Partly | Yes, with Monitor | | One policy across every AI platform | No, each platform governs its own agents | Yes | So do you still need the controls built into your AI platform? Yes. Keep them switched on: they decide which systems and tools an agent can reach. Tool Policies standardise the governance and guardrails across any platform you deploy, and decide how agents behave once they’re connected. Some platforms are adding argument checks in beta, but each one governs only its own agents, so a company running Copilot, Claude and Glean side by side writes the same rule three times. With Tool Policies, it writes the rule once. “IT and functional leaders couldn’t safely enable more access, because of what ungoverned access would imply. Tool Policies is the exhaustive answer to that problem.” Guillaume Lebedel, CTO and Co-founder, StackOne How do Tool Policies work? Every policy has three parts: - Who it applies to: everyone, or users and groups synced from your identity provider, with named exemptions. - Where it applies: the whole project, a connector category, one connector or one linked account. A category rule also covers connectors you add later, and a name pattern like delete catches every matching tool. - What it does: five rule types. PII redaction strips personal data or blocks the call. Tool rules block tools. Value rules limit what a tool accepts, such as payments between $25 and $500. Field rules hide or protect fields by path. Semantic rules ask a plain-language question. StackOne checks the input before it calls the business system, and the response before the agent sees it. Rules compile to Cedar, the open-source policy language built by AWS, where if two rules disagree the deny always wins. PII redaction runs on StackOne’s own state of the art model, which finds email addresses, phone numbers, SSNs and card numbers anywhere in a payload. Build a policy in the no-code builder, have the StackOne Assistant draft it, or write it as Cedar or JSON. Every rule can run in Monitor first, which records who it would affect without blocking anything, and every decision is logged. Guillaume describes the rollout sequence we recommend in Monitor first, then enforce https://www.stackone.com/blog/agent-policy-rollout-monitor-first/ . Semantic rules: one question instead of a hundred field names Say you want to keep pay away from every agent. The obvious way is a field rule: you name the field to hide, such as salary. But every system names it differently. One HR system calls it salary, another base pay, a third pay rate, so you’d need a rule for each one. And a Slack message about someone’s raise has no field to name at all. A semantic rule asks a question instead, such as “Is this compensation?” or “Does this message contain unreleased financial results?”, and a decision model answers it on every call. One rule covers the HR systems you connect today and the ones you add next year. When the model cannot decide, the field stays masked. Tool Policies in action How do you control which finance actions and fields AI agents can access? If a finance team wants one agent for analytics and forecasting and another to pay supplier bills, the security review is going to turn up four problems. The payments agent could pay any amount. Anyone with access to supplier records could change where the money goes. Contractors could delete records. And the analytics agent would see every supplier’s bank details. Tool Policies fix each one with a rule for the group it applies to, using the groups already in your identity provider: - Accounts Payable can pay through an agent, between $25 and $500 per payment, and can prepare invoices but not authorize them. A $250 bill goes through. A $4,800 payment is stopped before the finance system is called. - Procurement can read supplier records, but a change to a bank account number is refused. A request to change a supplier’s bank details in SAP is blocked and logged. - Contractors cannot run any tool matching delete , on any connector. - Data teams can read accounting records with bank details masked. See it end to end in our vendor payment scheduling https://www.stackone.com/use-cases/ai-agent-vendor-payment-scheduling/ and AP invoice processing https://www.stackone.com/use-cases/ai-agent-ap-invoice-processing/ use cases. Can AI agents analyse patient data under HIPAA? Take a healthcare provider with several clinics. Its operations team wants an agent to read patient messages and support tickets and report why appointments get rescheduled, or which clinics get the most billing questions. The analysis needs what each message says, not who sent it. HIPAA’s minimum necessary standard asks for exactly that: use only the patient data a task needs. So the identifiers stay out of the agent’s context window and out of your logs: - A PII redaction rule on the patient support and ticketing connectors replaces email addresses, phone numbers, SSNs and card numbers with a tag that names the type, such as