Tool Policies: one policy engine for every tool your AI agents call

AI agent rollouts frequently stall at the security review stage. A finance team wants an agent to pay supplier bills, but security blocks the request because the payments connector can handle any amount to any supplier and delete the record afterwards. In IT and security teams this is where most agent deployments grind to a halt. 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. McKinsey’s 2026 survey of about 500 organizations found that nearly two-thirds named security and risk as the top barrier to scaling agentic AI. Buyers echo the same concern: an IT director leading an internal 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 provide the granularity security teams require. 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 level. As the StackOne CTO wrote in August, 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. Gartner’s advice is to build these controls in before a breach occurs, and StackOne 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.

Tool Policies vs built-in platform controls

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 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: Monitor first, then enforce.

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: finance use cases

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 the vendor payment scheduling and AP invoice processing use cases.

HIPAA-compliant patient data analysis

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 , wherever they appear in the text.
• Field rules mask the fields that name the patient directly, such as name, date of birth and home address.
• Advanced Logs redaction removes personal data from stored request and response bodies.

The 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.

Hiding salary and personal data from AI agents in HR systems

People 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:

• 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.
• Field rules mask Social Security number, personal email, home address and bank details on employee records.
• PII redaction catches an SSN or phone number typed into a case note, where no field rule can reach.
• The Total Rewards team is exempt, so their agents still see pay.

A 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. See how this fits an onboarding agent in the employee onboarding use case.

Why StackOne is the most complete way to secure AI agent tool calls

Every 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, ChatGPT, Copilot, Gemini Enterprise, 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. Securing 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. A security team asks three things of any gateway, and StackOne answers all three:

• Who can do what? Tool Policies, per user or group, across every connector.
• What leaks out? PII redaction runs on our own model. On connector data it scores 97.9% span F1, against 68.1% for Microsoft Presidio.
• What gets in? Defender is on by default 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.

Where to start

Tool Policies are available today in early access on Gateway Team and Gateway Enterprise, under Project Settings > Policies. If 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 and we will write the first rules against your own systems. To 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.