Control your agent’s actions

Delegate the work and keep control of the actions

Give your agent room to complete routine work, with the oversight you choose.

An access policy defines which actions your agent can take, when it needs your approval, and what it must stop. Autonomy explains how these rules work with instructions and connected accounts.

You'll configure and test a policy for your own agent before handing off work. This lets you check its limits before relying on it to act on your behalf.

What you'll learn

Choose how your agent updates apps: Decide whether changes can proceed or need your approval for each type of run.
Add specific restrictions: Limit an app or action after choosing which run types may write.
Review and test the result: Check the proposed actions, save the policy, then try work you want to allow and stop.
Narrow the scope with JSON: Choose the run type and connected app before reaching for individual action names.

Before you start

Use a saved, active agent you own. To change a workspace agent's policy, you must be a workspace Owner.
Connect the app your agent needs and authorize the account and scopes for its work. A policy does not connect an app or grant account access.
Use test content you control. The worked example uses native Gmail and a test mailbox.

Set up the policy in your own words

First decide which types of run may write without asking and which need your approval.

Open the agent's access policy

Open the saved agent and select About.
Select Autonomy, then find Access policy.
Alternative: From Work or Library, select Configure to open the agent's configuration.
Migrate to a policy: Complete the short migration below.
Current policy: Continue to the next step.

Illustration of About and Autonomy selected, with Migrate to a policy visible for an agent using the old controls. — Illustration: About → Autonomy, before migration.

Choose how your agent updates connected apps

Decide when your agent can make changes in connected apps without asking and when it needs your approval. Choose this for each type of run.

Allow lets writes proceed without asking, within the agent's account access and other restrictions.
Ask requires your approval before a write.
Deny blocks the write.

In Access policy, describe which run types may write without asking and which require your approval. For example:

Access policy request box with the conversation-Allow and scheduled-Ask request above Draft policy. — Example: describe permissions for each type of run in the request box.

Choose conversation and schedule permissionsPrompt

Allow writes in regular conversations where I can respond. Ask before writes from scheduled runs.

Type of run	Decide first
Conversations	May the agent save, send, and change data without asking while you work together, or does it need your approval?
Scheduled work	May scheduled runs complete writes without asking, or do they need your approval?
Live Mode	May background checks make changes without asking, or do they need your approval?
MCP clients	May work started by an MCP client write without asking, or does it need your approval?
Incoming email	May work started by an incoming email write without asking, or does it need your approval?
Webhooks	May work started by a webhook write without asking, or does it need your approval?
Delegated agent work	May work delegated from another agent write without asking, or does it need your approval?
Queued follow-ups	May queued follow-ups, reminders, and resumptions write without asking, or do they need your approval?

Review and save the write permissions

Select Draft policy.
In Proposed, check the write permissions for each run type, including rules preserved from migration.

Proposed policy showing Added conversation-Allow and scheduled-Ask rules, with the instruction to save to put them in force and Cancel and Save controls. — Proposed shows the changes to review. Save applies them.

Select Save when the proposal matches your choices.
Check Current policy and each rule's In force status.

Add a rule for a specific app or action

For example, your agent may help prepare email replies in Gmail. However, you want to review the drafts on your own before sending.

Access policy request preserving the run-type permissions, allowing Gmail drafts, and denying sending, replies, forwards, and existing drafts, with Draft policy below. — Illustration: add the Gmail restriction while keeping the run-type permissions.

Add a draft-only Gmail restrictionPrompt

Keep the existing run-type permissions. Allow preparing drafts in Gmail. Deny sending Gmail messages, including replies, forwards, and existing drafts.

Type of run: Your earlier permissions decide whether updates may proceed without approval.
Gmail actions: Request a Deny rule for sending while keeping draft preparation allowed.
Select Draft policy.
Hyperagent shows the unsaved rules in Proposed for you to review.

Review the proposed permissions

Expand the proposed rule and check:

Actions: Which actions does it cover?
Connection: Which account or app does it apply to?
Conditions: How is each condition checked?

Proposed policy retaining conversation Allow and scheduled Ask, adding Gmail draft Allow and explicit sending Deny, with all four sending actions expanded and Save visible. — Illustration: Added marks the Gmail changes. The conversation and schedule permissions remain.

For this example, confirm:

Check	What to confirm
Draft preparation	Your agent may prepare and save drafts. Sending has a separate Deny rule.
Sending	An explicit Deny covers sending, replying, forwarding, and sending an existing draft.
Connection	The rule covers your intended Gmail connection. Resolve any warning before saving.

If something is missing: Revise your request and select Draft policy again.
Review the actual proposed rules; they may differ from the illustration.
Use Show JSON to inspect their exact actions and scope.

How Hyperagent checks a rule

Strict rule: Hyperagent checks an explicit condition directly.
Judge, per write: Hyperagent uses a separate AI policy checker to evaluate each proposed write against your rule.

Save the reviewed policy

Select Save.
Check that Current policy contains the rules you reviewed.
Confirm that their restrictions show In force before testing.

Entire Current policy panel with conversation Allow, scheduled Ask, Gmail draft Allow, strict sending Deny, Every other write, and Show JSON; the rules show In force. — Illustration: after saving, Current policy contains the reviewed rules and their In force statuses.

If a rule is not in force, or Autonomy cannot load the policy, stop and follow its explanation.

Test an allowed action and a stopped action

Start fresh work with your agent.
Try one action the policy should allow and one it should stop or send for approval.
Check the thread's tool activity and the result in the connected app.

Illustrative thread requesting a Gmail test draft, showing Using Gmail · Save draft and the agent's confirmation that the draft has not been sent. — Illustration of draft preparation in the thread, not live test evidence.

Use JSON for more granular control

JSON lets you edit the exact actions, app connection, conditions, and run filters in a rule. Use it to require approval for particular app changes or block an individual native action. The JSON schema reference describes every field and its values.

Open the current policy

In the agent's Autonomy section, find Current policy.
Select Show JSON, then Copy policy JSON to save a backup.
Select Edit.

Illustrative walkthrough opening Show JSON, copying the saved policy, and selecting Edit to reveal the JSON editor and Preview button. — Example: open the JSON, copy it, then select Edit.

Set permissions for each type of run

Operations: Include append, write, and delete together in ops.
Permission: Choose Allow, Ask, or Deny.
Choose a type of run in the dropdown to see an example.

Type of run

conversation-writes.jsonc

{  // The permission for this type of run.  "effect": "allow",  // Include all three operations to cover updates across apps.  "ops": [    "append",    "write",    "delete"  ],  // Select the type of run this rule applies to.  "trigger": {    // Exclude schedules and other triggers with their own write settings.    "electionCarrying": false,    // Someone can answer an approval in this conversation.    "attended": true  }}

Comments explain the fields. Copy returns valid JSON without comments.

Advanced: approval availability

Approval examples require an available approval path for the run.

Each example is one rule for the policy's rules array.
See Thread filters for advanced setup and the entire rules schema.

Add an app-specific rule

After choosing write permissions by run type, add conditions for a particular app:

Set integration.slug to the connection's actual app identifier.
Put write in the ops array.
Put the condition in where.semantic.

Ask before changing Notion contentExample

With conversation writes set to Allow, this rule adds Ask before Notion changes:

notion-changes.jsonc

{  // Require approval when this rule applies.  "effect": "ask",  // For an app-based rule, write checks every call, including reads.  "ops": [    "write"  ],  // The connected app this rule applies to.  "integration": {    // Use the identifier from your actual connection.    "slug": "notion"  },  // When this rule applies.  "where": {    // Describe the changes that need approval.    "semantic": "The request would create, update, delete, or share Notion content, or change its permissions."  }}

Comments explain the fields. Copy returns valid JSON without comments.

App-based rules also check reads

For an app-based rule, write brings every app call into the policy check, including reads. Hyperagent's AI policy checker judges whether each call meets the condition.

Put the new rule objects inside the existing rules array.
Preserve unrelated rules and the outer policy settings.
Keep the version Hyperagent provides. If a change needs a different format, use Draft policy to describe the rules and let Hyperagent choose the compatible version.
Select Preview.
Check the write permissions for each run type, then the app-specific rule.
For the Notion example, confirm that the proposal adds an approval requirement and preserves the scheduled Ask rule and explicit denials.

Save and test both rules

Select Save.
Check Current policy and each rule's status.
Test through the run types you configured. A successful conversation does not demonstrate that a schedule or MCP run works.

With these examples, test:

A conversation write that should proceed under Allow.
A scheduled write that should pause under Ask.
A Notion change that should require Ask, even in the allowed conversation.

Use native action names when you need individual tools

Start with an app-based rule for connections such as standard Notion or Airtable.
For a native integration, put exact names from the action catalog in ops, without integration.slug.
For example, ops: ["GmailSendDraft"] selects the action that sends an existing Gmail draft. It does not cover every way to send email.

What you'll learn

Before you start

Set up the policy in your own words

Open the agent's access policy

Choose how your agent updates connected apps

Review and save the write permissions

Add a rule for a specific app or action

Review the proposed permissions

Save the reviewed policy

Test an allowed action and a stopped action

Use JSON for more granular control

Open the current policy

Set permissions for each type of run

Add an app-specific rule

Save and test both rules

FAQ

What's next

Access policy JSON reference

Understand autonomy

Existing agents: move your saved permissions into a policy

Test draft preparation and the sending restriction in Gmail

Why does my agent still ask after I save an Allow rule?

The app has Edit access. Why is the action blocked?

Can I allow one scheduled task without allowing every scheduled write?

Does drafting or previewing change the agent's permissions?

Why does the same approval keep returning after I approve it?

Can an unattended run ask for approval?

How do I undo a JSON edit?

Access policy JSON reference

Understand autonomy