Before an Agent Acts, Control What It Can See and What It Can Touch

Web pages contain text written for people, machines, analytics tools, accessibility, and sometimes agents. Hidden or irrelevant instructions can steer a model away from the user’s task. Sensitive data may also appear in the page or browser session.

Sanitize the page before the model reads it. Remove scripts and irrelevant interface text, detect prompt-injection patterns, mask sensitive values, and retain the clean representation used for the run. The agent should not decide which hostile instruction to ignore after it has already absorbed it.

Input control goes beyond blocking attacks. A task may require one order record without exposing the rest of the customer account. A browser agent may need the visible form fields without access to stored passwords or unrelated tabs.

Use isolated sessions, allowlisted domains, redaction, and task-specific context. Close access after the run. A convenient persistent browser profile can become a broad credential vault.

GitHub confirmed a 2026 compromise that began with a poisoned third-party VS Code extension on an employee device and led to exfiltration of internal repositories. The incident shows why agent security cannot stop at model behavior. Extensions and automation components can reach code and credentials below the agent layer.

Review extensions, pin dependencies and CI actions, rotate secrets after an incident, and remove privileges the workflow does not need. An agent can execute a compromised component faster than a person and across more repositories.

Use explicit scopes for files, repositories, accounts, payment limits, and target systems. A model may recommend an action. Deterministic controls should block actions outside the allowed boundary.

Autonomous security testing makes the principle easy to see. The agent needs written scope, allowed techniques, stop conditions, and a human responsible for the result. The same pattern applies to sales, finance, browser work, and infrastructure changes.

External sends, money movement, production changes, secret rotation, account deletion, and destructive security actions need a named reviewer. The agent should prepare evidence and explain the proposed action without gaining the final authority.

Approval does not repair a weak review screen. Show the source, affected assets, expected consequence, checks, and rollback. A reviewer should not have to trust the agent’s summary of its own work.

Keep the sanitized input reference, permissions, tool calls, files or records touched, approvals, and results under one run. Protect secrets and personal data inside the log. Store identifiers or redacted evidence when full content creates another risk.

Test incident response before launch. The owner should know how to stop the agent, revoke access, identify affected systems, and preserve evidence. Speed without a stop button is poor operations.

A new tool, integration, domain, or action changes the threat model. Recheck permissions and input handling when the workflow expands. Do not treat the security review from the prototype as permanent approval.

Track blocked injections, denied actions, expired credentials, reviewer edits, and incidents. Those measures show whether the controls work and where users keep requesting access the system should not grant.