Block actions across every connector, hide the fields an agent doesn’t need, keep PII out of systems it shouldn’t reach, and test each rule before you enforce it.
From every connector to a single field.
Personal fields masked, salary changes refused, PII redacted. Enforced for 3 groups.
Companies already connected through StackOne
SOC 2 Type IIA connection gives the agent every tool and every field. Policies decide which tools run, which fields come back and what data can go in or out, for each user or group.
Inside an allowed tool, the agent can read or change anything, whatever your policy says.
Your security and privacy rules apply on every call, across connectors, users and groups.
See a protected ERP field stop a change for a group, or a tool restriction stop a request for an individual user.
Change the supplier’s bank account number in SAP.
SAP S/4HANA
Update Business Partner BankApplies to Procurement group
Protected field
Bank account numberThe Procurement group can’t change bank account numbers. No bank details were updated.
Bank account number unchanged
StackOne evaluates policies for the user the agent acts for. Tool rules, value rules, semantic rules and PII checks run on the inputs before the business system is called. Field rules, PII redaction and semantic rules run on the response before the agent sees it.
Business system Called only if allowed A denied tool or input value, or an input a semantic rule or PII check refuses, stops the whole request. Nothing reaches the business system.
Denied fields are masked and PII is redacted before the response reaches the agent. The rest of the record stays available.
Every evaluated policy is recorded with its mode and decision, including what Monitor only would have done.
Block tools across every connector, hide the fields a task doesn’t need, limit the values an agent can send, and check the data going into and out of each call.
Tool rules
Block tools by name or pattern, such as *delete*, across a connector category, one connector, one linked account or the whole project. Scope the rule to everyone, named users or groups synced from your identity provider, with exemptions.
Example rule · ContractorsFor the Contractors group, block every tool matching *delete* on every connector.
Gmail
Notion
Asana*delete*personio_delete_personPersonioBlockedsalesforce_delete_opportunitySalesforceBlockedslack_delete_fileSlackBlockedsalesforce_get_opportunitySalesforceExisting accessField rules
Mask response fields by path, such as the bank account number on an employee record, and refuse changes to protected fields. An onboarding agent can read 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
Value rules
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.
Between $25 and $500 USD
For Finance, block payments outside $25 to $500 in USD.
Keep routine payments within your approved limit.
XeroBlock when type is “anyone”
"type": "user""type": "anyone"For Revenue operations, block public sharing before the tool runs.
Other sharing values are not blocked by this rule.
Google DriveDraft or submitted
For Accounts payable, block changes that authorize an invoice.
Prepare the invoice while keeping authorization protected.
XeroSemantic rules
Write the rule as a plain-language question. A decision model answers it for each field or payload, on inputs before the tool runs and on responses before the agent sees them, whatever the system calls the field.
Example rule · FinanceFor everyone outside Finance, block Slack, email and Notion messages that contain unreleased financial results. The agent can still summarise the close for Finance.
Does this message contain unreleased financial results?
Applies to slack_send_message, gmail_send_message and notion_create_page
PII redaction
StackOne’s own model finds email addresses, phone numbers, SSNs and card numbers in inputs and responses, then redacts the span or blocks the call. It doesn’t rely on field names, so it catches PII inside ticket text and notes.
Example rule · Customer supportRedact PII in Zendesk responses and block writes to Jira and Slack that contain it. The agent still escalates the bug.See the benchmark
The customer asked us to send invoices to <POLICY_REDACTED:
PII redacted in the response. The rest of the ticket stays readable.
PII detection on connector data
Span F1 on 247 Connector PII field values, and false positives on 129 connector field values that contain no PII. Full benchmark on the PII Redaction page.
Span F1. Higher is better
False positives. Lower is better
The admin describes the rule and the assistant drafts it for review. It looks up your groups, connectors, tools and linked accounts as it writes, and flags what a pattern might miss. Try the examples below and switch between Cedar and JSON.
Hide PII fields in tool responses and block requests that change those fields. Keep other fields within their existing permissions.
Enforcement
forbid (
principal,
action in [
StackOne::Action::"readField",
StackOne::Action::"writeField"
],
resource in StackOne::Label::"pii"
);{
"effect": "forbid",
"principal": {
"op": "All"
},
"action": {
"op": "in",
"entities": [
{
"type": "StackOne::Action",
"id": "readField"
},
{
"type": "StackOne::Action",
"id": "writeField"
}
]
},
"resource": {
"op": "in",
"entity": {
"type": "StackOne::Label",
"id": "pii"
}
},
"conditions": []
}forbid (
principal,
action == StackOne::Action::"writeField",
resource in StackOne::Category::"hris"
)
when {
resource.path like "*compensation*"
};{
"effect": "forbid",
"principal": {
"op": "All"
},
"action": {
"op": "==",
"entity": {
"type": "StackOne::Action",
"id": "writeField"
}
},
"resource": {
"op": "in",
"entity": {
"type": "StackOne::Category",
"id": "hris"
}
},
"conditions": [
{
"kind": "when",
"body": {
"like": {
"left": {
".": {
"left": {
"Var": "resource"
},
"attr": "path"
}
},
"pattern": [
"Wildcard",
{
"Literal": "c"
},
{
"Literal": "o"
},
{
"Literal": "m"
},
{
"Literal": "p"
},
{
"Literal": "e"
},
{
"Literal": "n"
},
{
"Literal": "s"
},
{
"Literal": "a"
},
{
"Literal": "t"
},
{
"Literal": "i"
},
{
"Literal": "o"
},
{
"Literal": "n"
},
"Wildcard"
]
}
}
}
]
}forbid (
principal,
action == StackOne::Action::"invokeTool",
resource
)
when {
resource.name like "*delete*"
};{
"effect": "forbid",
"principal": {
"op": "All"
},
"action": {
"op": "==",
"entity": {
"type": "StackOne::Action",
"id": "invokeTool"
}
},
"resource": {
"op": "All"
},
"conditions": [
{
"kind": "when",
"body": {
"like": {
"left": {
".": {
"left": {
"Var": "resource"
},
"attr": "name"
}
},
"pattern": [
"Wildcard",
{
"Literal": "d"
},
{
"Literal": "e"
},
{
"Literal": "l"
},
{
"Literal": "e"
},
{
"Literal": "t"
},
{
"Literal": "e"
},
"Wildcard"
]
}
}
}
]
}forbid (
principal,
action == StackOne::Action::"writeField",
resource
)
when {
(resource in StackOne::Connector::"netsuite"
|| resource in StackOne::Connector::"xero")
&& resource.path == "payment.amount"
&& !(
context.args.hasTag("amount_minor")
&& context.args.getTag("amount_minor") has num
&& context.args.getTag("amount_minor").num >= 2500
&& context.args.getTag("amount_minor").num <= 50000
&& context.args.hasTag("currency")
&& context.args.getTag("currency") has str
&& context.args.getTag("currency").str == "USD"
)
};{
"effect": "forbid",
"principal": {
"op": "All"
},
"action": {
"op": "==",
"entity": {
"type": "StackOne::Action",
"id": "writeField"
}
},
"resource": {
"op": "All"
},
"conditions": [
{
"kind": "when",
"body": {
"&&": {
"left": {
"&&": {
"left": {
"||": {
"left": {
"in": {
"left": {
"Var": "resource"
},
"right": {
"Value": {
"__entity": {
"type": "StackOne::Connector",
"id": "netsuite"
}
}
}
}
},
"right": {
"in": {
"left": {
"Var": "resource"
},
"right": {
"Value": {
"__entity": {
"type": "StackOne::Connector",
"id": "xero"
}
}
}
}
}
}
},
"right": {
"==": {
"left": {
".": {
"left": {
"Var": "resource"
},
"attr": "path"
}
},
"right": {
"Value": "payment.amount"
}
}
}
}
},
"right": {
"!": {
"arg": {
"&&": {
"left": {
"&&": {
"left": {
"&&": {
"left": {
"&&": {
"left": {
"&&": {
"left": {
"&&": {
"left": {
"hasTag": {
"left": {
".": {
"left": {
"Var": "context"
},
"attr": "args"
}
},
"right": {
"Value": "amount_minor"
}
}
},
"right": {
"has": {
"left": {
"getTag": {
"left": {
".": {
"left": {
"Var": "context"
},
"attr": "args"
}
},
"right": {
"Value": "amount_minor"
}
}
},
"attr": "num"
}
}
}
},
"right": {
">=": {
"left": {
".": {
"left": {
"getTag": {
"left": {
".": {
"left": {
"Var": "context"
},
"attr": "args"
}
},
"right": {
"Value": "amount_minor"
}
}
},
"attr": "num"
}
},
"right": {
"Value": 2500
}
}
}
}
},
"right": {
"<=": {
"left": {
".": {
"left": {
"getTag": {
"left": {
".": {
"left": {
"Var": "context"
},
"attr": "args"
}
},
"right": {
"Value": "amount_minor"
}
}
},
"attr": "num"
}
},
"right": {
"Value": 50000
}
}
}
}
},
"right": {
"hasTag": {
"left": {
".": {
"left": {
"Var": "context"
},
"attr": "args"
}
},
"right": {
"Value": "currency"
}
}
}
}
},
"right": {
"has": {
"left": {
"getTag": {
"left": {
".": {
"left": {
"Var": "context"
},
"attr": "args"
}
},
"right": {
"Value": "currency"
}
}
},
"attr": "str"
}
}
}
},
"right": {
"==": {
"left": {
".": {
"left": {
"getTag": {
"left": {
".": {
"left": {
"Var": "context"
},
"attr": "args"
}
},
"right": {
"Value": "currency"
}
}
},
"attr": "str"
}
},
"right": {
"Value": "USD"
}
}
}
}
}
}
}
}
}
}
]
}The same rule in Cedar or JSON. Audience and mode are assigned separately.
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.
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.
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.
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.
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.
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.
The policy is evaluated on every matching call and nothing is blocked or masked. Each decision is recorded.
See which calls would have been denied or masked, for which members, and which rule matched.
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.
Trace each governed request to its user, connector and policy decisions. See what was blocked, masked or redacted, and what Monitor only would have denied. Open any logged call, choose Use in policy, and the assistant drafts a rule from it. Start a policy from a log.
Send Message
Slackreq_8f21b4
MatchedSemantic rule · “Does this message contain unreleased financial results?” The answer was yes, so the request was refused before execution.
No matchPII check · No email addresses, phone numbers, SSNs or card numbers were found in the message.
No matchTool rule · Send Message does not match *delete*, and the user is not in the Contractors group.
Before executionThe message contained unreleased financial results. Nothing was posted to Slack.
Get Worker
Workdayreq_b47a92
MatchedPII field group · Protected values were masked before the response reached the agent. The rest of the response remains available.
No matchThis policy restricts writes. It does not block an employee read.
MatchedThe output-field rule matched in Monitor only. Its decision is recorded without applying an additional mask.
Response filteringPII fields were masked. The rest of the response was returned.
Delete Opportunity
Salesforcereq_c95e13
MatchedTool · Delete Opportunity is restricted for Alex Morgan (Revenue Operations Manager). The request was blocked before execution.
MatchedThe selected tool also matches this Monitor only policy. It contributes no enforced restriction.
No matchThe PII field rule did not match this tool-level evaluation.
Before executionThe tool was denied. No request was sent to Salesforce.
Each combines the rules above. Read what it would do in the request logs, then enforce it.
One rule blocks every tool matching *delete* across all connectors for the Contractors group.
Watch it in Monitor, enforce it, then open the logged deny.
A semantic rule asks “Does this message contain unreleased financial results?” on Slack, email and Notion send tools, for everyone outside Finance.
The agent can summarise the NetSuite close for Finance. Posting it to a shared channel is blocked.
PII redaction on Zendesk responses, a field rule hiding the card number, and a PII block on writes to Jira and Slack.
The agent still escalates the bug.
Set fixed rules on connectors, tools, fields and values. Add semantic rules and PII checks on what goes into and comes out of each call.
Expand a control to explore example policies.
Precise access controls
SAP S/4HANAXeroWorkday
SalesforceGoogle Drive
Slack550+ connectorsSelect any subset across your connected systems. salesforce_delete_opportunityslack_delete_file*delete*Explore 34,000+ actionsName patterns are case-sensitive, and * is the only wildcard. Semantic rules
Scope each restriction to users or groups. Policies narrow existing permissions; an applicable deny rule takes precedence.
Control the tools, fields and data your teams’ agents can reach.