# Autonomy Source: https://www.hyperagent.com/docs/concepts/agents/autonomy > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Understand what an agent can do on its own, what needs your approval, and what its access policy blocks. An email assistant can prepare replies in Gmail without sending them. Another assistant can send replies, but only after you approve each one. Autonomy lets you decide how much of the job an agent can complete on its own. An access policy sets rules for actions such as saving a draft, sending an email, or updating a record. You decide which actions the agent can complete, which need approval, and which it must not take. **Autonomy** describes how much an agent can do without asking you. An **access policy** records the rules for actions through its integrations. Scout prepares email drafts but cannot send them through the named Gmail actions. Beacon prepares follow-up messages and asks before sending. These illustrative agents have similar tools, but different permissions. ## What determines whether an agent can act [#what-determines-whether-an-agent-can-act] Three things determine whether an agent can take an action: * **Instructions** tell the agent what to do, such as preparing email replies for your review. * **Integration access** provides authentication to an external account and the scopes someone authorized the agent to use. To act on that account, the agent must first have an [integration set up](https://www.hyperagent.com/docs/integrations) with the required scopes. * **Access policy** checks whether the agent can perform the action under the conditions you have set, including whether it needs your approval. An access policy turns your boundaries into rules for specific actions. A rule can depend on who receives a message, what it contains, or whether the agent is running unattended. For example, you can let an agent save email drafts while requiring approval before it sends a message to a customer. The policy checks the proposed action against these rules before it proceeds. ## Permission levels [#permission-levels] Permission levels determine how much control you keep over an action: delegate it to the agent, review it before it happens, or block it. An access policy can assign different levels to different actions within the same integration, so you can allow draft preparation while requiring approval to send. #### Allow The agent can complete the action without asking you when the policy conditions and integration access permit it. #### Ask The action pauses for your approval. The agent can proceed only after you approve it. #### Deny The action is blocked. Approval cannot override an explicit denial. Existing or migrated policies may show **Withholds**. It preserves the write restriction for that type of run. As with Ask, a narrower Allow rule does not release the hold. Withholds does not request approval by itself on unattended runs. Keep existing `write_limited_default` values when editing JSON; use the three permissions above for new rules. ## How access policies check actions [#how-access-policies-check-actions] Access policies use two kinds of check: **Strict rule** for conditions that can be checked directly, and **Judge, per write** for conditions that require interpreting an action's content. A write is an action that saves, sends, or changes data. A single policy can use both kinds of check. Hyperagent checks the proposed action before allowing it to proceed. In the policy view, **Decided by** shows which kind of check applies to each part of a rule. #### Strict rule Hyperagent checks the action against explicit conditions, such as a named action, a supported email recipient, or a run type. A strict denial blocks the action even if you offer to approve it. #### Judge, per write A separate language-model check reviews the proposed action and its inputs against your rule, such as whether a message promises a price. Each action gets its own check. The judgment can be uncertain or wrong. This example policy uses both kinds of check. **Save draft** uses judgment for each draft. **Send message**, **Reply to message**, **Forward message**, and **Send draft** use strict denials. “Never send” covers those named native Gmail actions, including sending an existing draft. ### How Judge, per write works [#how-judge-per-write-works] Hyperagent runs this check separately from the agent doing the work: * **Review the request:** A language model receives the rule's wording and condition, the proposed tool action, and its inputs, such as an email's recipients and body or the fields being changed. * **Check the condition:** The model determines whether that specific action meets the rule's condition. For example, does the request fetch existing notes, or change them? * **Apply the permission:** Hyperagent uses that result to apply the rule's Allow, Ask, or Deny permission alongside other applicable rules and account restrictions. For app-based connections, this check also runs for searches and reads. Each request is checked on its own. ## What happens when no rule decides an action [#what-happens-when-no-rule-decides-an-action] When no rule decides an integration write, **Every other write** is the policy's default: Hyperagent asks for approval in a conversation where someone can respond. Without an available approval path, the action is blocked. Set an explicit write permission for [unattended work](https://www.hyperagent.com/docs/concepts/agents/invocations) you want the agent to complete on its own. Existing agents may still use the old **Auto** or **Ask first** controls until you [migrate their settings](https://www.hyperagent.com/docs/guides/set-up-access-policy#migrate-existing-settings). Start by deciding whether writes may proceed or need approval in conversations, scheduled work, and other run types you use. Then add restrictions for particular apps or actions. An app-specific Allow does not cancel a run-type Ask for the run type. Before delegating unattended work, check that your rules show **In force**, then try an action you want to allow and one you want to block. ## Current limits [#current-limits] * **Bundle installs:** A bundle cannot install an agent that carries a policy. Publishing an individual Marketplace listing can work when Hyperagent can convert its policy for installation. * **Team duplication:** Policy-governed agent items are skipped; the rest of the team can still duplicate. Other agent-copy workflows depend on whether Hyperagent can carry the rules safely. * **Missing judge verdict:** If the checker cannot return a usable answer, Hyperagent holds the action when that answer is needed to decide its permission. An uncertain condition is different: that rule does not apply, and other rules or the default decide. ## Set up or migrate an access policy [#set-up-or-migrate-an-access-policy] [Control your agent’s actions](https://www.hyperagent.com/docs/guides/set-up-access-policy) Choose write permissions by run type, then add restrictions for specific apps or actions. [Access policy JSON](https://www.hyperagent.com/docs/concepts/agents/autonomy/access-policy-json) Look up the policy schema, run filters, and exact native action names. [Migrate an agent](https://www.hyperagent.com/docs/guides/set-up-access-policy#migrate-existing-settings) Review an existing agent's saved permissions and turn them into policy rules. ## FAQs [#faqs] Instructions guide the agent's behavior. An access policy checks proposed integration actions before they proceed. Use a policy to make approval a requirement for specific actions, such as sending email. No. Approval cannot override an explicit denial. To permit that action, you need to change the policy. Some unattended runs can request approval through Inbox. Without an available approval path, the action cannot proceed. Choose the run type's write permission, then add restrictions for the work it should complete on its own. A judged rule applies only when the check finds that its condition is met with enough confidence. If it is uncertain, other rules may decide the action; otherwise, **Every other write** applies. If a required check fails to return an answer, the action stays on hold. Look for **In force** in the policy view. If a rule has a different status, read its explanation. Test an action you expect it to allow and one you expect it to block before relying on it for unattended work. Hyperagent checks every MCP call. Conditions use judgment for each call, including conditions about destinations or accounts. Review **Decided by** to see how a rule is checked, and review account-specific rules when you connect a different account. Browser actions, sandbox scripts, and other tools without an integration policy check rely on the agent following **Ask first**. For those tools, asking first is an instruction to the agent rather than an enforced approval step.