Skip to main content
Policies are in early access. User interfaces may change and not every capability is live yet (see Capabilities). For feedback or suggestions, contact our support team.
Policies control which tools an agent may use, and how, on behalf of the member it acts for. StackOne checks the active policies that apply to that member before a tool call reaches the provider, and refuses the call when an enforced policy denies it.
Flow diagram with three lanes. An AI agent makes a tool call and policies are checked. Allowed: the provider is called and the response returns unchanged. Redact PII or Read a field: the provider is called and the response returns with PII redacted or fields masked. Denied, including Write a field denials: the provider is not called and a refusal is returned. All three responses come back to the AI agent. Write a field is marked as not applied in the current early access phase
Policies are available on Gateway plans, and are enabled per organization. If the page reports that Policies are not enabled, contact StackOne support.

​
How a policy is evaluated

A policy carries a single rule that allows or denies capabilities. Rules are made up of 4 parts: Four guarantees hold across every policy:

A deny always wins

When policies overlap, a matching deny refuses the call whatever any allow says.

Policies narrow access

Connector Profile scoping and account access apply restrictions before policies.

Policies follow the member

Policies apply when the member is known, which is the case for AI platform sessions. A call made with a project API key is memberless — govern that traffic with Connector Profile scoping instead.

Policies stay in their project

A policy belongs to the project it is created in and governs calls made in that project only. To apply the same rule in several projects, create it in each.

​
Capabilities

A capability is the kind of access a rule governs: running a tool, reading or writing a field, or receiving PII in responses. Denying one removes that access for the users or groups the rule covers.
Write a field rules do not currently apply in the current Early Access phase. The rules can be saved but this capability will not be taken into account when or how tools are called.
Rules can carry more than one capability. Capabilities are alternatives rather than conditions: the rule applies where any one of them matches, so adding a second says “or also” rather than narrowing the first. Each is scoped on its own terms, so one rule can deny a tool outright on one connector and only mask a field on another.

​
Create a policy

1

Open Policies

Select the project, open Project Settings > Policies, and click Create policy. Give the policy a descriptive name.
2

Pick the mode and status

Two settings control whether the policy acts:
  • Status: Active policies are consulted from the project’s next call. Inactive policies are stored and never consulted.
  • Enforcement: Monitor only records decisions without refusing anything. Enforce refuses the calls the policy denies.
Start new deny rules in Monitor only, then monitor the logs for recorded decisions. Once you’re happy, set it to Enforce.
3

Choose who it applies to

Select Everyone, Users, or Groups, then search for the users or groups the rule covers.
4

Choose what it does

Select Deny to refuse the capability for those users or groups, or Allow to state permitted use without restricting anything.
5

Set the capability and its targets

Add the capabilities the rule governs:
Denying Use a tool refuses the call.Choose which targets it applies under Applies to:
  • Everything covers every tool in the project.
  • A connector category covers every tool on every connector in the category, including connectors added later.
  • A connector covers every tool on the connectors you pick.
  • An account covers the tools of specific Linked Accounts. Search accounts by name or owner.
  • Specific tools lets you pick a connector, then the tools on it by name.
To narrow the tools covered by the target selection, enter a name pattern under Tools matching (see the pattern syntax below). An empty pattern covers every tool the targets include, so a deny refuses every call to them. A capability takes either specific tools or a pattern, not both.

  • * is the only wildcard, and it matches any run of characters.
  • A pattern has to cover the whole name: salary matches only something named exactly that, so use *salary* to match it anywhere.
  • Matching is case-sensitive.
  • ?, [a-z], and {a,b} are ordinary characters here, not wildcards. A pattern using one saves cleanly and then never matches anything.
6

Add exemptions

For a deny rule, use Exempt from this rule to name users or groups the rule does not apply to. Another matching deny can still refuse the call.
7

Review and create

Review the policy:
  • Plain Text: the panel footer restates the rule in plain words, for example:
    Everyone in this project may not use a tool matching *delete* on Workday, except Finance (Group).
  • Cedar: the exact statement the engine will evaluate, in Cedar syntax. The view is read-only; change the form and the statement follows.
  • JSON: the same statement in Cedar’s JSON encoding.
Then click Create policy.
If you used the assistant, the button reads Accept changes and create. See Build a policy using chat.
Create policy panel with Policy chat on the left and the form on the right, showing a policy named Contractors cannot use tools that delete records, Enforcement set to Monitor only, Status set to Active, the audience set to the Contractors group, and a Deny rule on the Use a tool capability

A deny rule on the Create policy panel, with Monitor only and Active selected and Fields / Cedar / JSON above the form.

​
Build a policy using chat

Policy chat is available on policy create and edit. Describe the rule you want in your own words and the form will be updated automatically, showing you the suggested changes:
  • Suggestions are highlighted in the form, with the previous value shown underneath.
  • Each suggestion can be applied or reverted individually.
  • All changes can be applied using the buttons at the top of the form or simply by clicking Accept changes and create/Accept changes and save.
Create policy panel split in two, with Policy chat on the left showing completed search_principals and update_policy_draft tool calls and an explanation of the proposed rule, and the policy form on the right with a bar reading 3 changes from the assistant need review

Policy chat beside the form. The assistant looked up the Contractors group, proposed a deny rule, and left three changes marked for review.

​
What policy chat can access

Policy chat can look things up in the project as it drafts, and the transcript shows each lookup as it runs:
By default, only a tool call’s tool, connector and caller are exposed.With advanced logging enabled, the assistant can read the request/response payloads to help define field related capabilities.
For example, using a prompt like:
Stop contractors deleting records
  1. The assistant searches existing groups, sets Who it applies to to Groups and populates with Contractors.
  2. Writes a deny on Use a tool with a *delete* pattern, with applies to set to Everything.
The chat will also flag to you what a rule may miss. E.g. A pattern matching delete does not catch a connector that uses tool names using remove or archive. So you can confirm and ask it to also apply these patterns.

​
Starting from logs

Policy creation can be initiated from a specific log instead of the policies page.
1
Go to StackOne Logs.
2
Select the log of a call you want to create a policy from.
3
Click Use in policy at the top of the panel.This takes you to the Policies page with the context of the log selected.
4
Either select an existing policy OR create a new policy by clicking Create policy.
5
The Policy chat now has the context of the log selected.Continue by using the policy chat to craft the policy. For example:
This call should not have been allowed to return salary
This person should not have been allowed to make it
See Build a policy using chat.

​
Testing a policy before enforcing it

Two checks come before enforcing:
  1. Test against personas: in the create and edit panel, Test this policy against personas shows what the rule would decide for the members you choose, without making a call.
  2. Monitor only: set the policy’s Enforcement to Monitor only and applicable tool calls are flagged as calls the policy would have applied to, while continuing unaffected.
Only once Enforcement is set to Enforce are tool calls blocked or modified as defined by the policy.

​
Duplicating policies

Instead of starting with a blank new policy, an existing policy can be used as a template.
1
On an existing policy’s row in the Policies table, click the … button. Then click Duplicate.
2
A new policy is drafted with the original policy’s details except:
  • Name: original name is appended with (copy).
  • Enforcement: set to Monitor only.
  • Status: set to Inactive.
3
Edit as needed then click Create policy when done.
A policy whose rule the builder cannot read, or that holds more than one statement, cannot be duplicated.

​
What a denied call returns

When an enforced policy refuses a tool call, the request fails with HTTP 403 before anything reaches the underlying provider. The refusal returns to the agent as the tool result.

​
Troubleshooting

  • It matches nothing. The pattern has to cover the whole name: salary only matches a tool named exactly that, so use *salary*. ?, [a-z], and {a,b} do not perform any special matching.
  • It misses tools you expected. Matching is case-sensitive: *Delete* misses workday_delete_worker. A pattern matches exactly rather than describing a behaviour: *delete* does not catch a tool named workday_remove_worker.
  • It matches more than you expected. * matches any run of characters, underscores included, so *create* could cover list_created_employees.
Check the following in order:
  1. The policy is Active.
  2. Its mode is Enforce.
  3. The acting member is in its audience (and not exempt).
  4. The call is made in the project the policy was created in.
  5. The tool name or pattern matches exactly, including case.
  6. The caller is a member connected through an AI platform, so the call carries their identity. A call made with a project API key alone names no member, so no policy governs it.
Yes, on an action log. Open the record and select the Policy tab.

​
Next steps

Scoping Connectors

Set which actions each Connector Profile exposes.

Groups

Maintain the groups your policies apply to.

Connector Profile Access

Control who can link accounts on a profile.

Observability

Configure request logging and retention.