Approvals and guardrails

Polo makes a change outside its own working copy only after someone approves it, or when an administrator has set a standing approval for that exact change. Reading never needs approval. This page covers the Approvals page, the rules in Settings → Approval rules, and the controls on what is sent to an AI model.

VideoApproving an exact operationPolo proposes the exact change; nothing runs until a person approves it.

Exact-operation approvals

When an agent wants to change something, it proposes one exact operation: the system, the target and the content. Examples are a saved Terraform plan, a rendered Helm release, one Slack message, or stopping one named machine. The approval covers that operation and nothing else. If the plan, the target or the arguments change, a new approval is needed.

The Approvals page has four parts.

Section	What it holds
Waiting for you	Changes you may decide. Review exactly what will run, then approve or reject.
Waiting for another approver	Changes you cannot approve yourself, and why.
Questions	Tasks paused until someone answers.
History	What happened to Polo’s latest changes, newest first.

Each change is titled in plain words, such as “Apply the Terraform plan for checkout (production)”. Its card says why Polo asks, which rule applies, when the request expires, and what Polo checks afterwards.

Decide on a change

1. Open the change from Approvals, from Needs you on Home, or inside its task.
2. Open the review, for example Review exactly what will run, and read the exact change. The approve button is enabled only after the review is current.
3. Press the approve button (Approve and execute, or a specific label such as Approve stop or Approve and send), or press Reject change and give a reason. Polo reads your reason before its next step.

After an approved change runs, Polo checks the result with a separate read and records the outcome.

Outcome	Meaning
Waiting for approval	Nobody has decided yet, or more approvals are needed
Approved · Polo is applying it	The change is running
Applied · not yet verified	It ran; Polo has not confirmed the result yet
Verified	A separate read-back matched the approved change
Failed	It did not execute, or it failed and was rolled back
Outcome unknown	Polo could not confirm that it ran. Open the task and press Verify outcome before asking for another change.
Rejected	A person rejected it. Nothing ran.
Expired	Nobody decided in time. Nothing ran.
Closed	The task ended or was canceled before anyone decided. Nothing ran.

Note

A saved plan can expire while it waits. The change can then no longer be approved, and Polo has to plan again first. The task offers Plan again.

Approval rules

Settings → Approval rules → Rules by environment sets, for each environment:

• how many approvals a change needs;
• who may give them (Admins only, or Admins and operators);
• whether the approver must be someone other than the requester;
• how long a request waits before it expires, in hours.

All other environments covers every environment without its own row. With no rules saved, Polo uses the built-in rules: one approval from an administrator or operator, and in production the approver must be someone other than the requester. Administrators can always approve, viewers never can. Only administrators can change the rules. New requests follow saved rules right away.

Some actions add a requirement of their own. For example, GitHub actions such as merging a pull request or rerunning a workflow need the final approval to come from an administrator.

If you cannot approve a change, its card says why: for example, you created the task and the rule wants a different approver. If nobody else can approve yet, invite a teammate under Settings → Team.

Standing approvals (pre-authorization)

A standing approval lets Polo make one exact change without waiting for a person. It is for a small, repeatable action you always allow, such as turning maintenance mode on when a service is down.

A standing approval covers the same environment, connection, change, target and arguments, including how Polo checks the result. Anything that differs waits for approval under the rules by environment.

1. Open Settings → Approval rules → Standing approvals and press Add standing approval.
2. Enter the exact Environment, then choose the Connection, Change and Target.
3. Choose the read tool under Check the result with, press Fill in the arguments template, and replace every REPLACE_ME with the exact value.
4. Set a Daily limit, Expires after (days) and a Reason.
5. Press Save standing approval.

A change approved this way is recorded as Approved by a standing approval, with the reason and who set it up. Only administrators can add or remove standing approvals. Removing one does not affect changes it already approved.

Caution

Changes that apply a reviewed plan always need a person to approve the exact plan. That includes Terraform, CloudFormation and Kubernetes deploys, image publishing, and database restores or migrations. They cannot have a standing approval.

Guardrails on an agent

Each agent carries guardrails that Polo enforces on every task. See Agents.

• Read-only. The agent can observe and report, and never proposes a change.
• Environments and services. Polo refuses tasks outside the ones you list.
• Tools. An agent can use only the tools switched on for it, and a task can be given fewer.
• Budgets. A task stops when it reaches its cost, token or time limit.

Tasks started by an alert or a monitor get investigation (read) tools only. Any fix is a separate proposal that waits for approval.

Forbidden actions on an agent are instructions, not enforcement. Use the controls above to block something.

Hide infrastructure identifiers from the model

Polo can replace the identifiers of your infrastructure with stand-ins before it sends an agent’s context to a model. It is off until an administrator turns it on.

1. Open Settings → AI models → Hidden identifiers.
2. Under What the model does not see, tick what to hide: IP addresses, email addresses, AWS account IDs, internal host names, Kubernetes names.
3. Press Save. It applies from each agent’s next step, running tasks included.

The model reasons with the stand-ins. Polo puts the real names back into its answer before anything runs, so tools act on the real systems and you read the real names.

Limits: Polo hides what it can recognise by its form or the field it is in. A name it cannot recognise, such as a service called checkout in a sentence, still reaches the model. Public host names and IPv6 addresses are not hidden. This feature has been tested with a stand-in model, not yet with a real model provider.

Rules for what is sent to a model

A workspace can write its own rules that act on text before any agent sends it to a model.

1. Open Settings → AI models → Sending rules.
2. Press Add common rules for a starting set (AWS access key IDs, private key blocks, card numbers, bearer tokens), or Add a rule and give it an ID.
3. Enter keywords or regular expressions, one per line. Keywords match whatever their case.
4. Choose what happens On a match.
5. Press Save rules. They apply from each agent’s next step, running tasks included.

On a match	Effect
Replace the match	The model sees a marker instead of the text. Nothing is put back afterwards.
Stop the model call	The call is not made. The task stops and names the rule.
Record it only	The text is sent unchanged and the match is recorded.

A task shows each rule that matched and how often, never the text itself. A rule Polo cannot evaluate stops the call if it is a stop rule; otherwise the task says the rule was not evaluated. A workspace can hold up to 30 rules, each with up to 20 keywords and 10 regular expressions. Only an administrator can change them. Like identifier hiding, these rules have not yet been exercised with a real model provider.

Related: Key terms and the operation contract.