{"slug": "tool-policies-one-policy-engine-for-every-tool-your-ai-agents-call", "title": "Tool Policies: one policy engine for every tool your AI agents call", "summary": "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.", "body_md": "# Tool Policies: one policy engine for every tool your AI agents call\n\n## Table of Contents\n\n**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.**\n\n## Why do AI agent rollouts stall at the security review?\n\nA 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.\n\nThe 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.\n\nBuyers 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”.\n\nThe 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.\n\nSo 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.\n\n## What are StackOne Tool Policies?\n\nTool Policies address the answers security needs before it signs off: who can do what, to what data, through which agent.\n\nStart 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?”\n\nTool 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.\n\nConnectors 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.\n\n## How are Tool Policies different from the controls built into AI platforms?\n\n| Control | Built into AI platforms | StackOne Tool Policies | \n|---|---|---|\n| Turn a connector on or off | Yes | Yes | \n| Allow or block individual tools | Yes | Yes, by name pattern across every connector | \n| Scope tool access by user or group | Partly, varies by platform and plan | Yes, with groups from your identity provider | \n| Limit input values, such as a payment cap | No, or beta rules without numeric limits | Yes | \n| Mask a response field, such as salary | No | Yes | \n| Semantic rules on tool inputs and outputs | Prompts only, or through your own policy server | Yes, built in | \n| Redact PII inside tool payloads | No | Yes, on StackOne’s own model | \n| Test a rule before enforcing it | Partly | Yes, with Monitor | \n| One policy across every AI platform | No, each platform governs its own agents | Yes | \n\nSo 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.\n\n“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.”\n\n**Guillaume Lebedel, CTO and Co-founder, StackOne**\n\n## How do Tool Policies work?\n\nEvery policy has three parts:\n\n- **Who it applies to:** everyone, or users and groups synced from your identity provider, with named exemptions.\n- **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.\n- **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.\n\nStackOne 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.\n\nBuild 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/).\n\n## Semantic rules: one question instead of a hundred field names\n\nSay 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.\n\nA 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.\n\n## Tool Policies in action\n\n### How do you control which finance actions and fields AI agents can access?\n\nIf 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.\n\nTool Policies fix each one with a rule for the group it applies to, using the groups already in your identity provider:\n\n- 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.\n- 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.\n- Contractors cannot run any tool matching `*delete*` , on any connector.\n- Data teams can read accounting records with bank details masked.\n\nSee 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.\n\n### Can AI agents analyse patient data under HIPAA?\n\nTake 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.\n\nSo the identifiers stay out of the agent’s context window and out of your logs:\n\n- 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 `<POLICY_REDACTED:EMAIL>` , wherever they appear in the text.\n- Field rules mask the fields that name the patient directly, such as name, date of birth and home address.\n- [Advanced Logs redaction](https://www.stackone.com/platform/pii-redaction/) removes personal data from stored request and response bodies.\n\nThe agent reads hundreds of messages and reports the top reasons for rescheduling without seeing who wrote any of them. Every redaction is recorded in the action log for your compliance team. A Business Associate Agreement is available on Enterprise plans where PHI is in scope. I covered the wider picture in [the reality of connecting AI agents to healthcare systems](https://www.stackone.com/blog/healthcare-agent-write-access/).\n\n### How do you hide salary and personal data from AI agents in HR systems?\n\nPeople Ops coordinators use agents for onboarding, leave and employee questions. They need job titles, start dates and managers, and they do not need salary, bank details or Social Security numbers. For the People Operations group:\n\n- A semantic rule asks “Is this compensation?” on every HR read and write tool, so pay is hidden whatever each HR system calls it, and a raise attempted through the agent is refused.\n- Field rules mask Social Security number, personal email, home address and bank details on employee records.\n- PII redaction catches an SSN or phone number typed into a case note, where no field rule can reach.\n- The Total Rewards team is exempt, so their agents still see pay.\n\nA coordinator asks for a new starter’s details and gets the title, start date and manager, with pay and identifiers removed before the agent sees the record. The coordinator may see more in the HR system itself: the policy governs the agent separately from the person, the gap Guillaume described in [say yes to the Copilot, not to the salary field](https://www.stackone.com/blog/copilot-salary-field-agent-policies/).\n\nSee how this fits an onboarding agent in our [employee onboarding use case](https://www.stackone.com/use-cases/ai-agent-employee-onboarding/).\n\n## Why is StackOne the most complete way to secure AI agent tool calls?\n\nEvery action an agent takes in your business is a tool call. Updating a record, sending a message, paying a bill: each one goes through a tool, whether the agent runs in [Claude](https://www.stackone.com/blog/best-mcp-gateway-for-claude/), [ChatGPT](https://www.stackone.com/blog/best-mcp-gateway-for-chatgpt-enterprise/), [Copilot](https://www.stackone.com/blog/best-mcp-gateway-for-microsoft-copilot/), [Gemini Enterprise](https://www.stackone.com/blog/best-mcp-gateway-for-gemini-enterprise/), [Glean](https://www.stackone.com/blog/best-mcp-gateway-for-glean/) or your own code. That makes the tool call the one point every agent passes through, and the place where security does the most good.\n\nSecuring a tool call down to the field means owning the tool. A gateway that passes calls through to other people’s MCP servers can allow or block a whole server. StackOne builds every tool itself, so a policy can reach inside the call: the amount on a payment, the salary field on an employee record, the phone number in a support ticket. That is why StackOne is a Tool Gateway and not an MCP gateway. I set out the difference in [MCP gateway vs Tool Gateway](https://www.stackone.com/blog/mcp-gateway-vs-tool-gateway/).\n\nA security team asks three things of any gateway, and StackOne answers all three:\n\n- **Who can do what?** Tool Policies, per user or group, across every connector.\n- **What leaks out?**[PII redaction runs on our own model](https://www.stackone.com/platform/pii-redaction/) . On connector data it scores 97.9% span F1, against 68.1% for Microsoft Presidio.\n- **What gets in?**[Defender is on by default](https://www.stackone.com/platform/prompt-injection-guard/) on every connector and blocks prompt injections hidden in the documents, emails and tickets agents read. It scores 95.9% balanced accuracy, against 71.9% for Meta Prompt Guard v2.\n\n## Where to start\n\nTool Policies are available today in early access on Gateway Team and Gateway Enterprise, under [Project Settings > Policies](https://docs.stackone.com/secure/policies).\n\nIf you are writing your first policy, start with the rule your security team keeps asking about, usually compensation, payments or deletes. Run it in Monitor for a week, then enforce it on the team that asked for the agent. If you would rather do that with us, [book a Tool Policies demo](https://www.stackone.com/demo/) and we will write the first rules against your own systems.\n\nTo see it first, join Alex live on LinkedIn on Thursday, October 29 at 9am PT. He’ll ask an agent to pay a $4,800 bill, give someone a raise and pull a patient’s phone number out of a ticket, and show Tool Policies stopping each one.", "url": "https://wpnews.pro/news/tool-policies-one-policy-engine-for-every-tool-your-ai-agents-call", "canonical_source": "https://www.stackone.com/blog/tool-policies-launch/", "published_at": "2026-10-15 17:38:23+00:00", "updated_at": "2026-10-15 17:56:44.589004+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "ai-products", "agent-protocols"], "entities": ["StackOne", "Gartner", "McKinsey", "Claude", "ChatGPT", "Microsoft Copilot", "Gemini Enterprise", "Glean"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/tool-policies-one-policy-engine-for-every-tool-your-ai-agents-call", "markdown": "https://wpnews.pro/news/tool-policies-one-policy-engine-for-every-tool-your-ai-agents-call.md", "text": "https://wpnews.pro/news/tool-policies-one-policy-engine-for-every-tool-your-ai-agents-call.txt", "jsonld": "https://wpnews.pro/news/tool-policies-one-policy-engine-for-every-tool-your-ai-agents-call.jsonld"}}