Agent Origin Sets

Expanded Definition

Agent Origin Sets describe a browser-side policy boundary for agentic workflows: the agent may inspect content from some origins, but only act back on a narrower, explicitly allowed set. That distinction matters because modern agents often operate inside authenticated sessions, where the browser can expose sensitive page data that should not become part of the agent’s decision path. In practice, the control reduces the chance that hostile or irrelevant cross-origin content can influence tool use, navigation, or submission behavior.

For security teams, the concept sits closer to execution control than to content filtering. It is not simply a list of “trusted websites”; it is a way to separate read authority from write authority so that a page the agent can see is not automatically a page the agent can modify. This fits the broader direction of agentic application governance described in the OWASP Agentic AI Top 10 and the risk-management approach in the NIST AI Risk Management Framework.

The most common misapplication is treating origin awareness as a display safeguard only, which occurs when teams block visible content but still let the agent infer or submit actions across unauthorised origins.

Examples and Use Cases

Implementing Agent Origin Sets rigorously often introduces routing and policy complexity, requiring organisations to weigh safer agent autonomy against tighter task completion limits.

• An internal support agent can read a customer portal and a knowledge base, but can only write updates to the portal origin, preventing accidental action on third-party embedded content.
• A browser-embedded procurement agent can inspect invoice data from a vendor domain, yet it may submit approvals only to the company’s finance application.
• A research agent can browse multiple public sources, but its prompt inputs exclude authenticated content from unrelated origins so session data does not leak into model decisions.
• A workflow agent can open a ticketing page and a status dashboard, but it cannot post back to the dashboard unless that origin is explicitly placed in the write set.
• In a high-risk deployment, the policy is paired with logging and review so unusual origin transitions can be detected before a tool call is executed.

These patterns align with agentic security guidance in CSA MAESTRO agentic AI threat modeling framework, which treats tool routing and boundary definition as part of the attack surface rather than a UX detail.

Why It Matters for Security Teams

Agent Origin Sets matter because browser-based agents inherit the complexity of authenticated web sessions, cross-origin content, and hidden execution paths. If the read boundary is too broad, untrusted page material can influence the model’s reasoning. If the write boundary is too broad, the agent can take actions on pages the operator never intended it to control. That creates a practical path to data exposure, unauthorized transactions, and policy bypass even when the underlying model is behaving as designed.

This is especially important in environments where agents interact with secrets, identity workflows, or sensitive admin interfaces. Cross-origin separation helps reduce the chance that a logged-in session becomes an exfiltration channel, which is why agentic controls increasingly appear alongside threat modeling using the MITRE ATLAS adversarial AI threat matrix and case-driven analysis such as the Anthropic — first AI-orchestrated cyber espionage campaign report.

Organisations typically encounter the operational impact only after an agent performs an unsafe cross-origin action or leaks session context, at which point Agent Origin Sets become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do synthetic test sets miss the most important agent failures?
• What is agent communication poisoning?
• What is a shadow agent and why is it more dangerous than a typical shadow NHI?
• A2A — Agent-to-Agent Protocol