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: Meet us at WeAreDevelopers World Congress 2026
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

Granular Permission 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.

app.stackone.com/settings/policiesOpen Policies in the StackOne app (opens in new tab, sign-in required)
Who it applies to

What the policy covers
Mask reads
PII Personal email Home address
Block changes
Bank details Salary Employment status
Block if
Amount > $500 Sharing = anyone Status = approved

Personal data masked, salary changes refused. Enforced for 3 groups.

Companies already connected through StackOne

  • SOC 2 Type II
  • Encrypted at rest and in transit
  • Every policy decision logged

Beyond tool permissions. A tool permission
is only the start.

Granular permission policies decide which systems, tools, fields and values an AI agent can read or change for a given user or group. A tool allowlist stops at the tool, and everything inside it is left to your application. Permission Policies pick that up. This is field-level access control for AI agents: StackOne checks every request, refuses denied tools and input values before the business system is called, and masks denied output fields on the way back, across 520+ connectors and 32,000+ actions.

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

Inside an allowed tool, the agent can read or change anything, whatever your policy says.

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

Your security and privacy rules apply on every call, across connectors, users and groups.

Permission 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 Permission Policies work. Every request runs the same route.
StackOne Permission 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.

Granular field and value permissions. 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 USD

$250 USD
Not blocked
$750 USD
Blocked

For Finance, block payment records above $500 USD.

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.

The Permission Policy builder. 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, so the engine had to be one we can generate for correctly, check before a rule goes live, and run inside the connector runtime. Cedar fits that shape. Rego, the language behind OPA, did not, and the reasons came out of our engine review rather than preference.

Shaped like an access rule

Cedar's principal, action, resource and context map one to one onto what a policy names: the member, the tool, the field and the value. A generated rule keeps that shape, which is what lets the builder write Cedar for you and validate it against the connector schema before it is saved. Rego is a general-purpose logic language. Generating correct Rego from thousands of action schemas is where our review found the most ways to be wrong.

Proven, not only tested

Cedar decisions are deterministic, and Cedar Analysis can prove that one set of rules is equivalent to, wider than or narrower than another. That is the property behind the guarantee that a policy only ever narrows access. Rego evaluation can raise errors at runtime and has no equivalent analysis.

Readable by the people who own it

A rule an admin cannot read is a rule nobody reviews. Products built on OPA end up compiling their own YAML into Rego so their users never see it, and OPA's maintainers argue against that pattern because it loses the tooling. A Cedar statement is short enough to sit next to its plain-English preview in the builder, and its Rust and WebAssembly runtime evaluates it inside the connector path in under a millisecond, with a matching forbid always winning.

Read more: Cedar validation, Cedar Analysis and the OPA discussion on YAML-wrapped Rego.

Rolling out Permission Policies. 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. How Monitor only and Enforce work, in the docs.

  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.

Permission 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. What a policy decision looks like in the logs.

Request logs3 recent requests

Create Payment

Xeroreq_8f21b4

Blocked
Origin owner
Priya Shah (Accounts Payable Lead)
Group
Finance team
3 policies evaluatedMode / decision
Limit payment amounts EnforceDenied

MatchedInput value · $750 USD exceeds the $500 USD 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.

Every Permission Policy control. Control the field.
Understand the context.

Set precise access and value conditions for your organization. Add smart rules that recognize sensitive content, record ownership, and where data is going.

Expand a control to explore example policies.

Precise access controls

Connector categoryApply an organization rule to any selection of business-system categories. ERP Accounting HRIS CRM+20 more categoriesChoose one category or combine several.

Example organization policies

  • Restrict ERP access for the Contractors group.
  • Protect compensation fields across HRIS connectors for your onboarding team.
Connector nameChoose the systems your organization’s rule applies to.SAP S/4HANAXeroWorkdaySalesforceGoogle DriveSlack520+ connectorsSelect any subset across your connected systems.

Example organization policies

  • Protect bank details in SAP and Xero for the Procurement team.
  • Restrict Workday access to selected staff or groups.
Tools and annotationsSelect any subset by exact name, wildcard or declared annotations.salesforce_delete_opportunityslack_delete_file*delete*Explore 32,000+ actionsRead only · Destructive · IdempotentFilter by annotations such as read-only or destructive.

Example organization policies

  • Select destructive tools for a Contractors restriction, or match names with *delete*. Name patterns are case-sensitive.
  • Browse readOnlyHint or destructiveHint metadata to select tools across connectors. The chosen tools define the restriction.
Tool inputChoose which inputs staff’s agents can change, and under which conditions. Salary · writeAmount > $500Sharing = publicA few examples from the inputs across 32,000+ actions. Select any field, group or value condition.

Example organization policies

  • For Finance, block amounts above $500 while keeping routine payment records available.
  • For Revenue operations, deny a change when sharing is set to public. A denied input field stops the entire request.
Tool outputChoose which returned fields to mask, using field groups, values and context. PII Personal email Bank detailsClassification = confidentialExamples from your connected systems. Apply rules to any subset of available output fields.

Example organization policies

  • Mask personal email for Contractors while keeping job titles readable.
  • Mask document content labelled Confidential while keeping the title visible. Apply a shared label to avoid listing each field.

Smart rules

Recognize sensitive contentDetect personal data in free text with StackOne’s own PII redaction models.Contact [PERSON] at [EMAIL] Names Email addresses Personal identifiers

Example policies

  • Redact names and contact details in a customer note.
  • Detect personal information inside a document, beyond known PII field labels.
Check who owns the recordUse the relationship between the requester and the record.Requesting user → their own record Requester Record owner

Example policies

  • Keep an employee’s access to their own personnel record.
  • Restrict access to records assigned to the requesting user.
Control where data goesConsider the source of sensitive data and its destination.Finance data → external chat · Blocked Source Destination

Example policies

  • Keep sensitive finance data out of an external Slack channel.
  • Prevent personal employee data from being sent to a public document.

Scope each restriction to users or groups. Policies narrow existing permissions; an applicable deny rule takes precedence.

  • Agent AuthConnects each member's accounts. Policies decide what the agent may do through them.
  • Prompt Injection GuardScreens tool results for planted instructions before the agent acts on them.
  • Agent Execution EngineThe request path every policy is evaluated on, with nothing stored by default.
  • Policies in the changelogWhat shipped, with screenshots of the builder, audiences and request logs.

Common questions. Permission Policies FAQ

Granular permission policies are rules that decide which systems, tools, fields and values an AI agent can read or change for a given user or group. StackOne Permission Policies apply them on every request the agent makes through the platform. 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. A policy can mask individual output fields or field groups such as PII in the response, and refuse writes to protected fields such as compensation or bank details before the request reaches the business system. The rest of the record stays available to the agent.
A tool allowlist decides which tools an agent may call. Role-based access in the business system decides what a human role can see. Permission policies sit between them: they apply to the agent acting for a member, narrow what that member already has, and reach individual fields and values inside an allowed tool.
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 Permission 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