Your AI Coworker Can Reach the Internet. Where Is It Allowed to Send Data?

The Internet Is a Permission, Not a Workplace Default

On October 7, Kaspersky published secure-by-design guidance for AI systems that included an unusually concrete recommendation: apply default-deny policy to external interactions, including tool arguments and network traffic. For a business running an AI coworker, that translates into a question more useful than “Can it browse?” Which destinations can it reach, with which data, for which job?

An AI coworker may need to check a supplier portal, pull an order status, or prepare a customer update. The same outbound connection that makes those jobs possible can also carry an entire customer file to a destination nobody approved. A polite instruction not to disclose data does not replace a network boundary. Nor does banning the browser solve the problem if a shell, webhook, integration, or newly installed package can still call out.

Kaspersky's guidance is not evidence that every deployment has leaked data, and its recommendations are not a certification for any product. Its contribution is to put network traffic in the same design conversation as permissions and isolation. OWASP's agentic application guidance also recommends outbound allowlists and denying unapproved destinations for execution environments. The business implication is direct: give each coworker an outbound route that matches its role, not a general-purpose path to the whole internet.

Why a Browser Restriction Is Not an Egress Policy

The common security conversation focuses on the visible action. A manager asks whether the AI coworker should be able to search the web or send an email. But data can leave through less obvious paths: an API request, a command-line HTTP client, a connector's callback, a log exporter, or an extension that phones home. Permission to call a tool is not the same as permission to send any payload to any host.

Consider a sales operations coworker. It reads a lead record, enriches it against an approved service, and writes a draft follow-up for a human to approve. Its legitimate network map includes the CRM and enrichment service. It does not need to upload the full pipeline to an unfamiliar analytics endpoint, contact a personal file-sharing site, or invoke arbitrary URLs found in a retrieved page. If all outbound HTTPS traffic is allowed, those distinctions exist only in the prompt.

This is especially important when external content enters a workflow. A web page or a vendor document can contain text that asks the coworker to send its working data elsewhere. That text is task data, not authority. A runtime control should deny an unauthorized transfer even if the coworker mistakenly interprets the instruction as part of the job. This is trust architecture: the policy survives a bad decision by the model.

A restrictive firewall rule by itself is not enough. A permitted host may support multiple operations; a valid CRM endpoint may allow both read and export, and a broad cloud-storage domain may host anyone's account. Network destination, account identity, API scope, HTTP method, requested object, and data classification need to be considered together. Outbound control is one boundary in a layered system, not a magic shield against all misuse.

What bad looks like

A business grants its support coworker access to customer tickets and a general shell on an agent server. The team disables the browser for safety, but the server can make outbound requests to any HTTPS address. A ticket includes a request to “verify” a customer list by posting it to a new site. The coworker or one of its tools follows that request. The prompt said not to share customer data, yet nothing technical stopped the transfer. The log records that the ticket was processed, not where the data went.

A less dramatic version is an extension update that silently contacts a new host. The business does not notice because outbound traffic has never been inventoried. Our earlier analysis of the OpenClaw memory-plugin compromise covers why a trusted integration can run code with the host's privileges; an outbound policy limits what such code can send even when the integration itself is the weak point.

What good looks like

The support coworker can read tickets through a scoped service identity. Its runtime can connect only to the ticketing service and a specifically approved status source. Sending messages uses a separate tool with an approved recipient class and a human checkpoint when customer data or a consequential commitment is involved. The egress layer records denied requests with destination, role, time, and reason, without dumping ticket contents into the log.

A test ticket carrying an unapproved URL is processed as untrusted data. The coworker can summarize it and flag the attempted redirect, but a real request to that host fails at the boundary. When the team needs a new integration, it adds a narrowly defined destination and API scope after review, then tests both a permitted request and a denied one. The result is not less useful work. It is work with a knowable route out.

Design Outbound Access Around the Job

An egress policy starts with work, not with a list of vendor domains. Define what the coworker actually needs to complete: which inputs it reads, which external services it queries, what it can create, and what stays with a human. A useful role description is operational: “Read open support tickets and product-status pages, draft replies, never send customer attachments to third-party sites.” A vague instruction to “help with support” cannot produce a testable access policy.

Separate network reachability from application authority

Allowing a destination answers only the first question. The CRM still needs a service identity restricted to the right records and operations. An approved provider domain may expose a read API and a bulk export API; network access to the domain must not silently authorize both. Use role-specific credentials, short-lived access where available, and application permissions that match the particular task.

This is why an allowlist of “trusted websites” often disappoints. It may permit a legitimate SaaS domain while ignoring tenant boundaries, upload paths, and record-level access. A small team can start with named services and dedicated accounts rather than trying to build a perfect content classifier. Record the exact API operations each role requires. Where a proxy or tool gateway can inspect request method, path, and arguments, enforce that contract there too.

Account for every outbound channel

Inventory browser navigation, search, shell commands, code execution, package installation, webhooks, connector callbacks, monitoring exporters, and model-provider traffic. Some paths may bypass a browser-level restriction entirely. Map which paths originate from the coworker's runtime, which come from a service you control, and which are provider-managed. A policy attached to one tool cannot police a second tool that makes direct network calls.

Put enforcement at the network or execution boundary actually used by the workflow. A container or sandbox can restrict egress from code execution; an outbound proxy can log and control destination requests; an integration layer can validate tool parameters. Do not claim a destination allowlist is enforced just because it appears in a document. Verify traffic from the same identity, execution environment, and network path the coworker uses in production.

Make exceptions narrow and temporary

A new supplier portal should not require the whole server to receive unrestricted web access. Create an exception for that role, destination, operation, owner, and expiration date. Ask whether a human can fetch the occasional document instead of opening a permanent route. If the requested host is a shared file-storage platform, inspect whether the policy can bind to a particular account or approved endpoint; a domain-wide exception may be too broad.

The October Kaspersky guidance includes default-deny interaction controls precisely because the set of plausible destinations grows as a coworker gets more Skills and integrations. Each new connection should be a small, reviewable change to its operating contract. A surprise destination in a ticket or document is not an integration request.

A Seven-Step Egress Review for a Small Business

You do not need a large security department to start. You do need a named owner and a negative test. Use one consequential role first, such as a coworker that reads customer records or touches finance data, and expand only after its boundary works.

1. Choose one role and one workflow. Write down the input, intended output, and external services needed for that exact job. Do not use “internet access” as a substitute for a destination list.
2. Classify the data it can see. Distinguish public reference material, internal operations, customer records, credentials, and regulated information. Mark which categories may leave the environment and for what purpose.
3. Trace actual outbound paths. Observe browser requests, code execution, connectors, webhooks, package downloads, and service calls using the role's real runtime. Separate model-provider traffic from business-system traffic so an exception for one does not authorize the other.
4. Constrain each path. Define permitted destinations and methods where your stack supports them. Use dedicated application identities and minimal API scopes. Deny arbitrary outbound network traffic from general execution environments unless the role genuinely needs it.
5. Test a legitimate task and a malicious detour. Confirm the normal status lookup still works. Then plant a harmless test instruction in a document asking for a synthetic customer record to be sent to an unapproved host. Verify the request is blocked and logged; do not use real customer data in the test.
6. Define the exception process. A human owner approves new destinations with a reason, scope, and review date. Expire temporary access automatically where possible. Re-run the negative test after changes to the network, connector, or execution environment.
7. Prepare an incident response. If an unapproved destination is attempted, identify the coworker, source content, tool used, reachable data, and whether bytes actually left. Pause the affected route, retain redacted evidence, rotate exposed credentials where necessary, and resume only after the boundary is verified.

These steps do not require pretending every external connection is hostile. They make the distinction between useful work and unapproved transfer enforceable. The strongest proof is not a beautiful architecture diagram; it is a normal task succeeding while the detour fails.

This review also creates a better human handoff. A denied request should not leave the coworker stuck or silently retrying through a different path. It should report what it was trying to do, why the destination was not approved, what data would have been involved, and what approved alternative is available. A human can then reject, approve a scoped exception, or perform the one-off action directly. Steerability matters as much as prevention.

FAQ

Q: What is an AI coworker network egress policy? A: It is a set of enforced rules controlling where a persistent AI coworker's tools and runtime can send outbound traffic. A good policy is tied to the coworker's role and includes destinations, application permissions, exceptions, logging, and a test that unapproved traffic fails.

Q: Is disabling web browsing enough to stop data leaving? A: No. A shell command, integration, webhook, package, or other outbound service call can still transfer data if its execution environment has network access. Test the full route the coworker actually uses, not just the visible browser feature.

Q: Should every AI coworker have a separate allowlist? A: Use role-specific rules for materially different jobs. Shared infrastructure can enforce common deny rules, but a public research role and a customer-data role should not inherit identical outbound authority. Record a named owner for each exception.

Q: What if an approved SaaS service hosts multiple customer accounts? A: An allowed domain is not enough. Bind access to a dedicated service identity, tenant, API scopes, and permitted operations. If your network layer cannot express that detail, enforce it at the application or tool gateway and verify both boundaries.

Q: Will default-deny access prevent a coworker from doing useful work? A: An unplanned deny can interrupt work, which is why you first map a legitimate workflow and test it. Build a clear exception and escalation path rather than leaving unrestricted access on permanently. The goal is safe completion, not a network that nobody can use.

Q: How often should we revisit the policy? A: Review it whenever a Skill, connector, service account, hosting environment, or workflow changes, and periodically with the role owner. An exception that was justified for a pilot should not become permanent by neglect.

If you're ready to give AI coworkers useful connections without treating the entire internet as an approved destination, Associates AI Teammates provides persistent agent servers and configurable roles for a team you can govern. View pricing and get started with a scope your staff can actually review.