Use Policy Advisor
Policy advisor lets a running sandboxed agent ask for a narrow network policy change after OpenShell denies a request. The agent submits a draft through policy.local, a developer approves or rejects it from outside the sandbox, and approved network policy hot-reloads into the same sandbox.
Policy advisor does not grant access automatically. The structured rule is the approval contract, and the agent’s rationale is supporting context.
Enable Policy Advisor
Policy advisor is disabled by default. Enable it globally when you want every sandbox on the selected gateway to expose the agent proposal surface:
You can also enable it for one sandbox, unless the key is managed globally:
Check the effective setting for a sandbox:
The output shows whether agent_policy_proposals_enabled is global, sandbox, or unset. A global value overrides sandbox-scoped values. To return control to sandbox-scoped settings, delete the global key:
Set the value before creating a sandbox when you want the first denied request to include policy advisor guidance. Running sandboxes poll settings and can enable the surface after startup, but startup enablement gives the agent the clearest first-denial path.
How It Works
When policy advisor is enabled, the sandbox supervisor turns on three agent-facing surfaces:
- It installs
/etc/openshell/skills/policy_advisor.mdinside the sandbox. - It serves
http://policy.localfrom inside the sandbox. - It adds
next_stepsto L7policy_deniedresponse bodies so the agent can find the skill and local API.
The loop has six steps:
- A sandboxed process attempts a network request that policy denies.
- For inspected REST traffic, OpenShell returns a structured
403body with fields such aslayer,host,port,binary,method,path,rule_missing, andnext_steps. - The agent reads the policy advisor skill, inspects the current policy, and optionally reads recent denial log lines.
- The agent submits one or more
addRuleproposals tohttp://policy.local/v1/proposals. - The gateway stores accepted proposals as pending draft chunks for the sandbox.
- A developer reviews the draft, approves or rejects it, and the agent waits on
/v1/proposals/{chunk_id}/waituntil a decision is available.
When a proposal is approved, /wait reports policy_reloaded: true only after the local sandbox policy covers the approved rule. At that point the agent can retry the original denied action once. If a proposal is rejected, /wait returns rejection_reason and validation_result so the agent can revise or stop.
What Gets Proposed
OpenShell has two proposal paths:
For REST APIs, prefer L7 rules over broad L4 access. A good proposal allows one method and the smallest safe path:
The current policy.local JSON shape covers L4 endpoints and REST method or path rules. Use Customize Sandbox Policies or Policy Schema Reference for policy fields that are not part of the agent-authored proposal surface, such as WebSocket credential rewrite, GraphQL operation matching, endpoint path scoping, and provider-owned policy bundles.
Policy advisor proposals do not add allowed_ips automatically. If a hostname resolves to an internal or private address, OpenShell’s SSRF protections still block the connection until a developer explicitly adds the required allowed_ips entry.
Review Proposals
Review pending chunks from the host:
The output shows the chunk ID, status, rationale, binary, and endpoint summary. For L7 proposals, the endpoint summary includes the protocol, method, and path:
Approve only when the structured rule matches the access you intend to grant:
Reject with guidance when the rule is too broad or points at the wrong target:
The rejection reason is returned to the agent through policy.local. The agent can use it to draft a narrower proposal.
Agent API
policy.local is available only inside the sandbox and uses plain HTTP:
If policy advisor is disabled, every route returns 404 feature_disabled, the skill is not installed for new sandboxes, and L7 deny bodies do not advertise policy.local routes.
What to Expect
Approved network rules hot-reload without restarting the sandbox. HTTP L7 keep-alive connections are closed at the reload boundary so the next parsed request uses the new policy. Raw streams remain connection-scoped, as described in Customize Sandbox Policies.
Policy advisor emits audit events into the sandbox log. Use these lines to trace the full loop:
Look for HTTP:* DENIED, CONFIG:PROPOSED, CONFIG:APPROVED or CONFIG:REJECTED, CONFIG:LOADED, and the final allowed request if the agent retries successfully.
Next Steps
- Use Customize Sandbox Policies for manual policy updates and L7 rule syntax.
- Use Policy Schema Reference for full YAML field details.
- Use Logging to interpret OCSF shorthand log entries.