Configuring access controls
Give your agents exactly the access they need — nothing more. Access policies let you define what each agent is and isn't allowed to do on the internet, and those rules travel with your team definition to any platform.
Why access controls matter
The most common complaint about AI agents isn't that they're too slow or too expensive — it's that they're unpredictable. An agent given access to a Zendesk API key has access to the entire Zendesk API. On a bad run it might read tickets, send replies, close issues, and bulk-delete records. The deployer consented to the integration; they didn't consent to every possible action within it.
Access policies solve this at the definition layer. You declare which actions are allowed, and the runtime enforces it. Destructive actions are blocked before they happen, not discovered after the fact.
Without an access policy — An agent has full access to every connected service. One bad run can delete or modify anything the integration allows.
With an access policy — The agent is restricted to the specific actions you define. Anything outside those rules is blocked automatically before the request is made.
How it works
Each agent in your team can have its own access policy — a set of rules that control which outbound calls it's allowed to make. When the agent tries to make a request, the runtime checks the rules before sending anything. A blocked request never leaves the system.
Rules can match on the service the agent is calling, the type of action (reading vs. writing vs. deleting), or the specific part of the service being accessed. The first matching rule wins; if no rule matches, a default applies.
Common patterns
Read-only agent — Allow the agent to fetch information but block all writes, updates, and deletions. Useful for research or reporting agents that should never change data.
Allowlist only — Block everything by default, then explicitly allow only the specific services the agent needs. Anything not on the list is blocked. The safest approach for sensitive environments.
Block a specific action — Allow everything except one dangerous endpoint — for example, preventing a support agent from deleting tickets even though it can read and reply to them.
Enforcement
Access policies are evaluated by Envelope's security proxy before any outbound request is made. Blocked calls return a clear error to the agent — the agent knows the action was refused, but no external request was ever sent.
The security view in your workspace shows every proxied request across all your teams — what was allowed, what was blocked, and which agents have no policy at all. See Security dashboard for how to read it.
Policies travel with the team definition to any platform. Enforcement details vary by runtime — see Security & privacy for platform-specific notes.