Skip to main content Announcing Tool Gateway MCP: the universal MCPRead the announcement
StackOne
Connectors
Pricing
Login
Book Demo Start Free
Connect

Connect to everything your agents need, without writing the infrastructure to get there.

Secure

Enterprise-grade controls to ensure your agent always meets security & compliance standards.

Optimize

Maximise agent efficiency – faster responses, increased accuracy, fewer tokens used.

Explore More Use-Cases
Next up: Connecting AI Agents Securely in Healthcare
StackOne
Connectors
Connect

Connect to everything your agents need, without writing the infrastructure to get there.

Secure

Enterprise-grade controls to ensure your agent always meets security & compliance standards.

Optimize

Maximise agent efficiency – faster responses, increased accuracy, fewer tokens used.

Use-Cases
Pricing
Book Demo Start Free

Policies for AI agents

Give agents room to work.
Control every field.

Control what your company’s AI agents can read and change, down to fields and values. Create policies with AI and apply them across users, teams and business systems.

Request Demo Read Policies docs

From entire connectors to a single sensitive field.

Set the limits for your agents

Enforce
Who it applies to

What the policy covers
Restrict exact names or patterns
salesforce_delete_opportunityExact
slack_delete_fileExact
*delete*Wildcard
Or filter by annotationRead onlyDestructiveIdempotent

Example restrictions across Salesforce, Slack and more. Name patterns are case-sensitive.

Matching tools blocked.For the selected users or groups.

Companies already connected through StackOne

Beyond tool permissions

A tool permission
is only the start.

Connecting your teams’ agents doesn’t decide which fields they should read or change. When access stops at a tool allowlist, those checks fall to your application. StackOne Policies let your organization set shared field and value controls, scoped to the teams and people using agents.

With tool-level access alone

The tool is allowed. What else?

Tool available to the agentAvailable
  • Read a recordSensitive fields included
    Read
  • Update a recordWritable fields exposed
    Write
  • Set a valueProvider validation only
    Value

More precise checks are left to your application.

With StackOne Policies

The right access, within limits.

Tool available to the agentAvailable
  • Read a recordPII fields masked
    Read
  • Update a recordProtected changes blocked
    Write
  • Set a valueYour conditions checked
    Value

Apply field and value rules across connectors, users and groups.

Policies in the conversation

The agent understands the task.
Policies define the limits.

See a protected ERP field stop a change for a group, or a tool restriction stop a request for an individual user.

Agent chat Policies enforced
ProcurementGroup

Change the supplier’s bank account number in SAP.

SAP S/4HANA

Update supplier bank details
Policy matched Enforce
Protect supplier bank details

Applies to Procurement group

Protected field

Bank account number
Denied

The Procurement group can’t change bank account numbers. No bank details were updated.

Bank account number unchanged

How it works

Every request runs the same route.
StackOne Policies sit on it.

StackOne evaluates policies for the member the agent acts for. A denied tool or input stops the request before the business system is called, and denied output fields are masked on the way back.

Before execution

A denied tool or a denied input value stops the whole request. Nothing reaches the business system.

After the call

Denied output fields are masked before the response reaches the agent. The rest of the record stays available.

Always logged

Every evaluated policy is recorded with its mode and decision, including what Monitor only would have done.

Field and value controls

Give every team’s agents
only the access they need.

Let agents work with a record while protecting its sensitive parts. Decide which fields they can read, which they can change, and which values are permitted.

Read and write controls

Protect what agents read.
Control what they write.

Set separate restrictions for reads and writes, using individual fields or groups such as PII. An onboarding agent can access a start date while personal email reads and salary changes stay blocked.

Example rule · Employee onboardingFor the onboarding group, deny personal email reads and salary writes.Explore employee onboarding

Onboarding group
Job titleReadExisting access
Start dateReadExisting access
Personal emailReadBlocked
SalaryWriteBlocked

Value conditions

Allow the action.
Constrain the values.

Keep a tool available while defining which inputs are acceptable. Set an amount limit, restrict a status change, or prevent public sharing. The same action can pass or be blocked depending on the value it carries.

Your conditions, across systemsApply ranges, exact values and combinations of conditions to the users or groups that need them.

Explore value conditions
Payment amountTool input

At most £500 GBP

£250 GBP
Not blocked
£750 GBP
Blocked

For Finance, block payment records above £500 GBP.

Keep routine payments within your approved limit.

Xero

Smart content rules

Recognize sensitive content,
even outside named fields.

A field name does not tell you what free text contains. Smart content rules recognize names, email addresses and personal identifiers inside notes and documents, using StackOne’s own PII redaction models, and mask them in the response.

Example rule · Customer supportFor the Customer support group, mask personal data found in ticket text.

Support ticket · free-text field Tool output

Customer PERSON asked to move billing to EMAIL and confirmed the account ending IDENTIFIER. Renewal is due next month.

Names Email addresses Personal identifiers

Personal data masked in the response. The rest of the ticket stays readable.

Inside the product

Describe the boundary.
Let AI draft the policy.

Set an organization policy in plain English or use the builder. Try the examples below, choose users or groups, and watch AI draft the rule. Switch between Cedar and its JSON representation.

Policy builder Active
Try a use case
Hide PII fields in tool responses and block requests that change those fields. Keep other fields within their existing permissions.
Who it applies to

Enforcement

Generated policyRead + write restrictions
Policy format
forbid (
  principal,
  action in [
    StackOne::Action::"readField",
    StackOne::Action::"writeField"
  ],
  resource in StackOne::Label::"pii"
);

The same rule in Cedar or JSON. Audience and mode are assigned separately.

Audience
Everyone
Mode
Enforce

PII field group

PII fields protected

PII fields are masked in responses. A request that changes a protected field is blocked in full. Other fields keep their existing access.

Why Cedar instead of OPA/Rego?

Our policies are generated from connector schemas and enforce your organization’s access boundaries. We chose Cedar for rules that can be checked before use, analyzed for permission changes and evaluated inside our connector runtime.

Check generated rules

Cedar validates policies against a schema, catching mismatched fields and types before evaluation. Its language keeps policy logic bounded.

Analyze permission boundaries

Cedar Analysis can compare whether policy sets are equivalent, more permissive or less permissive. That fits our principle that agent policies should only narrow existing access.

Embed the decision engine

Cedar’s Rust and WebAssembly implementations fit our embedded evaluation path. A matching forbid rule takes precedence; StackOne applies the decision to tool calls, inputs and outputs.

OPA/Rego is a mature choice for authorization and broader policy tasks, with strengths in partial evaluation and data filtering. Cedar’s narrower language and analysis model fit our generated policies; we accept its more limited partial-evaluation options.

Read more: Cedar validation, Cedar Analysis and OPA partial evaluation.

Roll out safely

Monitor first.
Then enforce.

Activate a policy in Monitor only, read what it would have done in the request logs, then switch to Enforce for a test audience before everyone.

  1. 1 Monitor only

    Activate in Monitor only

    The policy is evaluated on every matching call and nothing is blocked or masked. Each decision is recorded.

  2. 2 Request logs

    Review the request logs

    See which calls would have been denied or masked, for which members, and which rule matched.

  3. 3 Enforce

    Switch to Enforce

    Enforce for a test audience first, then for everyone. A matching deny stops the call or masks the field.

Scope each restriction to users or groups. Policies narrow existing permissions; an applicable deny rule takes precedence, and an exemption skips only that rule.

Policy audit trail

Everything logged.
Every decision auditable.

Trace each governed request to its user, connector and policy decisions. See what was blocked or masked, what didn’t match, and what Monitor only would have denied.

Request logs3 recent requests

Create Payment

Xeroreq_8f21b4

Blocked
Origin owner
Priya Shah (Accounts Payable Lead)
Group
Finance team

3 policies evaluated

Mode / decision
Limit payment amounts EnforceDenied

MatchedInput value · £750 GBP exceeds the £500 GBP limit. The request is refused before execution.

Review large payments Monitor onlyWould deny

MatchedInput value · This monitor rule also matches. It records its decision without blocking the request.

Protect personal data EnforceNo match

No matchThis rule did not match the evaluated resource. It did not contribute to the denial.

Before execution£750 exceeds the £500 limit. No payment was created.

Common questions

Policies FAQ

StackOne Policies give organizations shared control over what their AI agents can access, read and change. Apply restrictions by connector, connector category, tool name, input parameter, or output field, with conditions on specific values and audiences made up of users or groups.
A policy can cover an entire ERP category or a single field within one tool. Protect salary updates, prevent an agent from reading email addresses, or block an input when an amount falls outside a defined range. Tool-name wildcards such as *delete* let you restrict a family of actions.
Yes. Apply a policy to everyone in your StackOne organization, selected users, or groups. For example, prevent a procurement group from changing supplier bank details while letting it continue other work within its existing permissions.
Yes. Describe the restriction in plain English to generate a Cedar policy. Review the fields, conditions, audience, and generated rule before activating it. You can also configure the policy directly in the builder.
Yes. Apply a policy to a field group such as PII, across the fields assigned to that group. Control both reads and writes. Smart content rules also recognize sensitive information in free text, where a field name alone does not tell you what the content contains.
Smart content rules recognize personal data inside free text, such as names, email addresses and personal identifiers in a note or a document, and mask it in the response. AI policy generation helps you write a rule; smart content rules assess what the returned content contains.
Agent Auth connects an agent to the right accounts. Policies add precise restrictions on the systems, actions, and data the agent can access through those connections. Policies do not grant additional permissions.
Policies apply to calls made for members of your StackOne organization. API key calls and sessions without a member’s identity do not receive these member policies.
An enforced policy stops a denied tool call or input before execution, and masks denied output fields in the response. An applicable deny rule takes precedence. Exempting someone from one policy cannot override another applicable denial.
Monitor only evaluates a policy without blocking or masking, so you can inspect its decisions in request logs. Enforce applies the decision. Inactive policies do not apply, whichever mode is selected.
Yes. Request logs show every evaluated policy alongside its mode, match result, and decision. See which rule denied access, which policies did not match, and what a policy in Monitor only would have denied.
Manage Policies in Project Settings under Policies. Generate a rule with AI or configure its restriction in the builder, choose users or groups, review the Cedar rule, and select Monitor only or Enforce.

Set agent boundaries across your organization

Control the systems, tools, fields and values your teams’ agents can access.

Start Free Book Demo