# Access policy JSON Source: https://www.hyperagent.com/docs/concepts/agents/autonomy/access-policy-json > 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. Reference for policy documents, rule fields, conditions, and run filters. To get started with access policies, follow [Control your agent’s actions](https://www.hyperagent.com/docs/guides/set-up-access-policy). Use this reference when you need to edit the JSON directly. An [access policy](https://www.hyperagent.com/docs/concepts/agents/autonomy) defines an agent’s permissions through a policy document and its rules. Explore the schema below, or select an example to inspect its JSON. ## Policy document [#policy-document] The outer structure: version , mode , rules , and default . Full policy ## Rules [#rules] Each rule sets a permission ( Allow , Ask , or Deny ) for the actions it covers. Narrow that permission to particular apps, destinations, conditions, or thread types. Rules can cover different thread types and connected integrations. ## Thread filters [#thread-filters] Limit a rule to particular thread types and invocations. Define write permissions for every thread type before adding app-specific conditions. Follow [Control your agent’s actions](https://www.hyperagent.com/docs/guides/set-up-access-policy) to set them up. To remove run scoping, omit `trigger` rather than leaving an empty object. `write_limited_default` is a migration effect shown as Withholds. Preserve existing instances; do not add it to new rules. `allow_logged` is reserved and cannot be authored. See [migration from the old controls](https://www.hyperagent.com/docs/guides/set-up-access-policy#migrate-existing-settings) for the setup steps. ## Integration action names [#integration-action-names] Native actions are tools Hyperagent recognizes by name, such as `GmailSendDraft`. Search by integration, action name, or purpose. Put the action name in `ops` without adding `integration.slug`. ## Run examples [#run-examples] One schedule Chat approvals [Control your agent’s actions](https://www.hyperagent.com/docs/guides/set-up-access-policy) Write, review, save, and test a policy, or migrate from the old controls. [Understand autonomy](https://www.hyperagent.com/docs/concepts/agents/autonomy) See how instructions, connected accounts, and policy rules work together. ## FAQ [#faq] Add a single rule inside your policy's `rules` array, keeping the other rules. Only the **Full policy** example represents a complete document. See [where to open and copy the current policy](https://www.hyperagent.com/docs/guides/set-up-access-policy#open-the-current-policy) before editing. No. Preview shows the proposed policy. Select **Save** to apply it, then check **Current policy** to confirm the intended rule and its status. Follow [reviewing the proposed permissions](https://www.hyperagent.com/docs/guides/set-up-access-policy#review-the-proposed-permissions) for the checks to make before saving. For an app-based rule, use `integration.slug` with `ops: ["write"]`. For tools Hyperagent recognizes by name, choose exact action names from the [action catalog](#integration-action-names), or use all three operation classes together (`append`, `write`, and `delete`) for a run-type write rule. See the [rule patterns and fields](#rules) above for each format. Use `ops: ["write"]` even for read-only app rules. [Judge, per write](https://www.hyperagent.com/docs/concepts/agents/autonomy#how-judge-per-write-works) evaluates the condition in `where.semantic`, including on searches and reads. To allow reading only, describe what may be read and explicitly exclude changes. Yes, for a rule that names an action in `ops`, such as `GmailSendDraft`. Both conditions must match for the rule to apply. For a rule that selects an app with `integration.slug`, use `where.semantic` and leave out `where.deterministic`. A structured condition does not automatically make a rule Strict. The structured conditions documented here use **Judge, per write**; review the check method in Preview. There is no `strict: true` field. Another applicable rule or an Ask-first checkpoint may still require approval. Rules are not first-match wins: adding an Allow below a Deny or a whole-write Ask does not cancel it. Check overlapping rules and the run's settings. The connected account's permissions and any separate read-only restriction also still apply. With `ask`, your agent needs approval before taking the action. Unattended work may send the request to [Inbox](https://www.hyperagent.com/docs/concepts/teams/inbox). If that run cannot request approval, the action stays blocked. `trigger.attended` selects runs based on whether someone can approve in the run’s own conversation, including a web chat or a supported reply-enabled channel like Slack, iMessage, or Telegram. `resources.account` uses an **account-selection short ID**, not the full connection record ID. 1. Open a conversation with the agent whose connected account you want to use. 2. Ask: “List the connected Gmail accounts available to this agent, with their labels and account-selection short IDs. Don’t run any app actions or change anything.” Replace Gmail with your app. 3. Use the matching account’s `shortId` in `resources.account.value`, or put several short IDs in `resources.account.values`. This lookup may omit the short ID when only one account is available. An email address or `integration.slug` is not a replacement. 1. Open a conversation with the agent that owns the [schedule](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules). 2. Ask: “Show my existing schedules with their names and schedule IDs. Don’t create or change anything.” 3. Use the matching schedule’s `id` in `trigger.ids`, with `trigger.kind` set to `scheduled`. You can also open the schedule’s **History** link. In the URL’s `automation` parameter, the value after `schedule:` is the schedule ID. The colon may appear as `%3A`. Set `trigger.kind` to `scheduled` and put the actual schedule's trigger-record ID in `trigger.ids`. Without the IDs, the rule covers all runs of that kind. Omit `trigger` entirely to remove run scoping.