Policies - Stackone

Policies decide what an agent may do with a project’s connected accounts, 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. Policies live in Project Settings > Policies and need the organization Admin role.

Policies are available on Gateway plans, and are enabled per organization. If the page reports that Policies are not enabled, contact StackOne support.

The page is marked Early access: it is still changing, and the screens below may not match it exactly. The policies themselves are not a preview. An enforced policy is evaluated at runtime from the next call, so a rule saved here governs real traffic straight away. For feedback or suggestions, contact our support team.

The Policies page header with an Early access tag on the right, above a callout explaining that the page is still changing but an enforced policy is evaluated at runtime from the next call — The Policies page, marked Early access.

How a policy is evaluated

A policy has four parts. The builder walks through them in this order.

Part	Options	What it means
Who it applies to	Everyone, Users, Groups	The members whose agents the rule governs. Groups come from Manage Groups.
What it does	Allow, Deny	A deny rule refuses exactly what it covers for that audience. An allow rule restricts nothing and cannot undo a deny.
Capability	Use a tool, Read a field, Write a field	The operation the rule covers. One capability per kind of access, each narrowed on its own terms. See Capabilities below.
Applies to	Everything, A connector category, A connector, An account, Specific tools	Where the capability is covered. Tools matching narrows any target with a name pattern.

Three rules hold across every policy:

A deny always wins. When policies overlap, a matching deny refuses the call whatever any allow says. Put exceptions inside the deny rule, under Exempt from this rule, rather than in a separate allow.
Policies narrow access. They never grant a tool the member could not already reach. Connector Profile scoping and account access still apply.
Policies follow the member. A call is governed when it carries the identity of an organization member, which is the case for sessions created when a member connects an AI platform. A call made with a project API key alone carries no member identity, so member policies do not apply to it. Keep Connector Profile scoping in place for that traffic.

Each policy also has a Status and an Enforcement mode:

Status and mode	Result
Inactive	Stored and never consulted.
Active, Monitor only	The policy is evaluated and the call goes through. Nothing is refused.
Active, Enforce	A denied call is refused before it reaches the provider.

Capabilities

Three capabilities, each scoped on its own terms.

Capability	What denying it does
Use a tool	Refuses the call. The agent may not run the tool at all.
Read a field	Masks the field in responses.
Write a field	Refuses calls that would change the field.

A rule can carry more than one. 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.

Only Use a tool changes what a call does today. StackOne stores rules built on Read a field and Write a field, and the preview and the sentence describe them accurately, but no field is yet masked or refused on their account. Build them if you want the rule written down; do not rely on them to enforce anything yet.

Create a policy

Open Policies

Select the project, open Project Settings > Policies, and choose Create policy. Give the policy a name that says what it restricts, such as Contractors cannot delete records.

Pick the mode and status

Under Enforcement, choose Monitor only to record decisions without refusing anything, or Enforce to act on them. Under Status, choose Active to consult the policy from the project’s next call, or Inactive to store it for later.Start new deny rules in Monitor only, and switch to Enforce once the preview reads the way you intend.

Choose who it applies to

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

Choose what it does

Select Deny to refuse the capability for that audience, or Allow to state permitted use without restricting anything.

Set the capability and its targets

Pick the capability the rule governs. Use a tool is the one that acts on a call today. Then choose where it applies:

Everything covers every tool in the project.
A connector category or A connector covers every tool on the connectors you pick, including connectors added later in that category.
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 match tools by name instead, enter a pattern under Tools matching, such as *delete*. A capability takes either specific tools or a pattern, not both. Choose Add capability to cover another capability, or the same one over a second selection; the rule applies where any of them matches.

Add exemptions

For a deny rule, use Exempt from this rule to name users or groups the rule should skip. An exemption skips this policy only. Another applicable deny can still refuse the call.

Review and create

A sentence at the top of the right-hand column restates the policy, for example Everyone in this project may not use a tool matching *delete* on Workday, except Finance (Group). Under it, Fields is the form you have been filling in; switch to Cedar or JSON to read the rule the engine will evaluate. Then choose Create policy.If you used the assistant, the button reads Accept changes and create until every change it made has been reviewed. See Build a policy with the assistant.

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 with the assistant

Policy chat sits beside the form in the create and edit panels. Describe the rule you want in your own words and it fills the form in for you, so you do not have to know which capability or target expresses what you mean. It is answered by Claude Haiku 4.5, named under the chat header. The assistant fills in the form and never saves:

Every change lands on the field it belongs to, marked AI, with the previous value shown underneath as Was ….
Each marked field carries its own Accept and Revert, and a bar at the top of the column carries Accept all and Revert all.
Until every marked change is accepted or reverted, the panel’s button reads Accept changes and create (or Accept changes and save when editing) and nothing is written.

A suggestion you disagree with costs nothing: revert that field and the rest of the draft stands.

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 it can look up

The assistant can look things up in the project while it drafts, and the transcript shows each lookup as it runs:

It can find	So you can say
Users and groups	Exempt payroll, without knowing the group’s id
Connectors and categories	Block writes to any HRIS connector
The tools on a connector	Stop the delete ones on Workday
Linked accounts	Only the Acme production account
A logged call, including its payload	Stop this tool returning some of the fields it returned

So asked to stop contractors deleting records, it looks up the Contractors group, sets the audience to it, and writes a deny on Use a tool with a *delete* pattern rather than making you pick the tools by hand. It also flags what a rule will miss. A pattern matching delete does not catch a connector that names the same operation remove or archive, and the assistant says so rather than leaving you to find out from a call that went through.

Starting from a logged call

A rule usually starts with a call that should not have happened. On a log record, Use in policy opens the Policies page with that call attached, and you can then tell the assistant what to do about it in words: this call should not have been allowed, or this person should not have been allowed to make it. It opens the list, not a particular policy. Where a rule did decide the call, the record’s Policy tab already names it; where none acted, there is no policy to open. Either way, which policy to change is your call: open an existing one, or create a new one. With advanced logging on, the assistant can also read that call’s payload, which is what lets it name the fields involved. Without it, the call’s tool, connector and caller travel, but the field paths do not.

The button appears only if Policies is enabled for your organization and your account can manage policies.

Reviewing what it changed

Policy form fields marked AI, each with Accept and Revert buttons, showing a Name field changed from empty and an audience changed from Everyone in this project to the Contractors group — Each field the assistant changed is marked AI, shows the value it replaced, and carries its own Accept and Revert.

The example prompts under an empty chat change with what you are doing: authoring a new policy offers whole rules, and editing an existing one offers changes to it, such as Exempt payroll and rename it to match. They are starting points, not fixed commands, so edit one before sending it.

The assistant proposes rules; it does not judge them. Read the sentence at the top of the column, and the Cedar tab if you want the exact statement, before accepting. The same guidance applies as to any new deny rule: start in Monitor only and switch to Enforce once it reads the way you intend.

Test a policy before enforcing it

Monitor only is how you check a rule before it refuses anything: the policy is consulted on every call it covers, and every call still goes through. There is no separate dry run. Leave a new deny rule in that mode until it covers what you intended.

Save it Active, in Monitor only

Active so it is consulted from the next call, Monitor only so nothing is refused yet.

Assign it to one user or group first

Not Everyone. A rule that is wrong is easier to find against one person than against the organization.

Make the calls it should cover

Connect through an AI platform as the member you are testing, and use read-only tools and test data.

Switch it to Enforce

Once it covers what you intended and nothing else. It takes effect from the next call.

To stop a live rule without losing it, switch it back to Monitor only rather than deleting it.

Manage policies

The Policies list shows each policy’s Applies to audience, Mode (Enforce or Monitor), Scope (Organization or This project), and Status. From a policy’s menu you can:

View and edit the rule. Saving a change writes a new version and keeps the previous one in the policy’s history.
Duplicate it. The copy carries the same rule and audience, is named <name> (copy), and lands Inactive and in Monitor only whatever the original was, so it does nothing until you have finished editing it. A policy whose rule the builder cannot read, or that holds more than one statement, cannot be duplicated, and the page says which.
Enforce or Stop enforcing to switch its mode.
Activate or Deactivate to start or stop consulting it.
Delete it, which also removes its version history. To stop a policy from acting without losing it, switch it to Monitor only or deactivate it instead.

Deactivating or deleting a deny rule widens access from the next call. The confirmation says so before you proceed.

What a denied call returns

When an enforced policy refuses a tool call, the request fails with HTTP 403 before anything reaches the provider. The body names the level that refused it, not the rule:

{
  "message": "Action 'workday_delete_worker' is not permitted by project policy",
  "errorType": "POLICY_DENIED_ERROR",
  "level": "project"
}

An AI platform surfaces that message to the person using the agent. An org level means the refusal comes from an organization-wide policy, which a project member cannot change.

Troubleshooting

How do tool name patterns work?

A pattern under Tools matching must cover the whole tool name and is case-sensitive. * is the only wildcard.

Pattern	Matches
`delete`	Any tool name containing `delete`.
`salesforce_*`	Every tool whose name starts with `salesforce_`.
`workday_get_worker`	That exact tool only.

Characters such as ? and [a-z] are literal. A pattern describes names, so *delete* matches tools named that way rather than every tool that deletes something.

Why is a policy not taking effect?

Check, in order: the policy is Active; its mode is Enforce; the acting member is in its audience and not exempt; the call is made in the same project, or the policy is organization-wide; and the tool name or pattern matches exactly, including case.Then check the caller. A call made with a project API key and no member identity is not governed by member policies. Connect through an AI platform as the member you are testing, and test with a read-only tool and test data first.

Can I see policy decisions in request logs?

Yes, on an action log. Open the record and select the Policy tab.It names the rule that decided the call, with the level, mode and version it ran at, and marks the level that settled it. Rules in force lists the others that were asked, and Record carries the user, client and run ids and when it was decided.Where no rule acted, the tab says which of the reasons applies rather than leaving a gap: Every rule in force had no opinion on this call, No rule was asked about this call, or that the policy layer errored. A rule that objected in Monitor only shows as Objected, but only watching, since it changed nothing.The tab needs Policies enabled for the organization.

Why can I not create the policy?

If the button reads Accept changes and create, or Accept changes and save on an existing policy, the assistant has changed fields that nobody has reviewed yet. Accept or revert each one, or use Accept all or Revert all on the bar at the top of the column. Saving does not accept them for you, so nothing reaches the engine that you have not read.If the button reads Create policy and still does nothing, the rule is incomplete. A capability needs a target, and a pattern and specific tools are alternatives rather than both.

What does the AI mark on a field mean?

That the assistant set that field in the current draft and you have not reviewed it. The value it replaced is shown underneath as Was …. Accept keeps the new value, Revert restores the old one. The mark is about where a value came from, not whether it is correct.Marks are per draft. Once accepted they clear, and a field the assistant set in an earlier session is an ordinary saved value.

What does the generated rule look like?

The preview shows one Cedar statement per policy. A deny rule is a forbid on the invokeTool action, with when conditions for the targets and pattern and unless conditions for exemptions. JSON shows the same statement in Cedar’s JSON form. You cannot edit the statement directly; change the form and the preview follows.

Next steps

Scoping Connectors

Set which actions each Connector Profile exposes.

Manage Groups

Maintain the groups your policies apply to.

Sharing Connector Profiles

Control who can link accounts on a profile.

Observability

Configure request logging and retention.

​How a policy is evaluated

​Capabilities

​Create a policy

​Build a policy with the assistant

​What it can look up

​Starting from a logged call

​Reviewing what it changed

​Test a policy before enforcing it

​Manage policies

​What a denied call returns

​Troubleshooting

​Next steps

Scoping Connectors

Manage Groups

Sharing Connector Profiles

Observability

How a policy is evaluated

Capabilities

Create a policy

Build a policy with the assistant

What it can look up

Starting from a logged call

Reviewing what it changed

Test a policy before enforcing it

Manage policies

What a denied call returns

Troubleshooting

Next steps