AI agents connect content, identities, applications, permissions, and data within continuous workflows. Existing security tools may approve each event independently while missing how one action influences the next. This creates five control gaps:
Closing these gaps requires controls that remain active throughout the browser session. Menlo Agent Runtime Security (MARS), utilizing Menlo AI Adaptive DLP and Menlo File Security, provides the context to inspect content, preserve attribution, protect sensitive data, restrict high-impact actions, and maintain session-level observability. Agents can continue performing approved work while consistent policy governs their activity and brings people into decisions that require human judgment.
An enterprise agent begins by researching a supplier online. It then pulls contract details from an internal repository, compares the information with procurement requirements, and updates the supplier’s record in a business application. Each action may comply with the policy applied at that step, even as the complete sequence creates risk. Understanding that risk requires seeing what the agent encountered, which data it accessed, how that information shaped its decision, and what it ultimately changed.
Endpoint Detection and Response (EDR), Secure Web Gateways (SWGs), Cloud Access Security Brokers (CASBs), and identity controls remain essential. However, they were designed primarily to evaluate individual events within human-led workflows. An AI agent can move across those control points without giving any one tool a complete view of the task.
That disconnect opens five control gaps:
Closing these gaps requires security that follows the agent across the full workflow, from the content it interprets to the action it takes.
Authentication establishes who or what may enter a system. Access policies define available resources, while traffic inspection evaluates connections and content in transit. Those controls establish an important starting point, but an agent keeps making decisions long after access has been granted.
Within a single workflow, an agent might interpret a webpage, combine what it finds with internal customer data, choose a course of action, and write the result into another application. The same credentials and permissions can follow it across that entire sequence. As the task develops, new content may redirect the agent or cause it to apply approved access beyond the original purpose. Sensitive information can then move between systems without a new human decision.
The browser session is where the agent’s objective, source content, enterprise applications, permissions, and data come together. Security needs to remain active there throughout the workflow. That means evaluating context as it changes, governing what the agent can access and do, and stopping or escalating actions that move beyond the approved task.
Prompt injection occurs when an agent treats untrusted content as part of its operating instructions. The injection can be embedded in a webpage, email, document, application field, or record returned by a search. When the agent encounters it, the content may direct the agent to abandon its assigned task, reveal information, access another system, or take an action that benefits an attacker.
Consider the agent researching a supplier. It visits the supplier’s legitimate website and retrieves a document that appears relevant to its review. Hidden within that content is an instruction directing the agent to collect internal pricing data and include it in an external request. The page loads normally, and the document contains no conventional malware. Because the agent uses valid credentials to access permitted information and trusted destinations, the surrounding activity also appears legitimate.
Reputation and traffic controls can therefore approve both the source and the resulting activity. They see acceptable destinations and authorized connections, but they may not recognize that untrusted content changed the agent’s behavior.
Runtime controls must evaluate content in relation to the agent’s approved task. They need to keep external content separate from trusted instructions, limit the actions that content can trigger, and prevent the agent from moving data beyond policy boundaries. When instructions conflict or an action carries significant risk, the workflow should pause and bring in a person to decide what happens next.
A malicious instruction also creates an attribution problem. Determining who authorized the resulting action becomes difficult when agents operate through a mixture of user sessions, service accounts, delegated permissions, and application tokens.
The supplier-research agent might begin inside an employee’s authenticated browser session, use a service account to retrieve internal records, and rely on a token to update the procurement platform. Every system can confirm that a valid account performed the action. That record may not indicate whether the employee requested it, whether the agent selected it independently, or whether external content redirected the workflow.
As more agents enter the enterprise, these access paths multiply. A single employee may delegate work to several agents, while one agent may perform tasks for multiple teams. Without clear ownership, security teams struggle to review access, investigate questionable activity, or determine who is responsible when an agent moves beyond its intended role.
Every agent needs a defined owner, an approved purpose, an access scope, and a record of delegated authority. Those details must follow the agent throughout the workflow.
Runtime policy provides the missing continuity. It can distinguish agent activity from human activity, preserve attribution as work passes between them, and enforce policy according to the actor performing each step. Security teams gain a record that shows which identity was used, which agent acted, who authorized the work, and whether the action remained within the approved task.
Once ownership is established, security teams still need to determine how much data the agent should receive. Agents depend on enterprise information to produce useful results, yet the records they access often contain far more than the task requires.
The supplier-research agent may need contract terms, pricing history, delivery performance, and renewal dates. It does not need bank account numbers, tax identifiers, employee contact details, or unrelated records stored in the same system. Giving the agent the complete record increases the amount of sensitive data that could be exposed through prompt injection, an incorrect action, or an unauthorized destination. Blocking the record entirely leaves the agent without enough context to complete its assignment.
Binary controls do not match the way agents use enterprise data. Broad access exposes sensitive details, while blanket blocking removes the context required for useful work. Both responses can slow approved deployments and encourage business teams to seek less-governed alternatives.
Runtime data controls offer a more precise approach. They can detect sensitive information as the agent accesses it, mask or redact protected values, and preserve the business context required for the task. The agent can evaluate a contract without seeing every personal or financial detail it contains.
Those decisions should reflect the full workflow: which agent is acting, which application holds the data, where the information is going, what type of data is involved, and what the agent intends to do with it. The goal is to provide the minimum usable data for each approved action.
Approved data access can still create risk when an agent has permission to act across several systems. For agents, privilege escalation can emerge when valid permissions accumulate across a workflow and support actions outside the assigned task.
The supplier-research agent may inherit access from an employee who can read contracts, update vendor records, retrieve files, and send external email. Those permissions make sense for the employee’s broader role. The agent’s assignment, however, may be limited to reviewing supplier performance and updating a status field.
If the agent begins changing payment information, downloading supporting records, and emailing the revised details to an external address, each system may record the action as authorized. The file repository permits the download, the procurement application accepts the update, and the email platform sends the message. Only the complete sequence reveals how far the agent has moved beyond its original task. As it stands, static permissions define the actions available to an identity.
Runtime controls add the task context needed to determine whether each action fits the approved workflow. They can prevent the agent from expanding its scope, block activity that conflicts with its assigned purpose, and flag consequential decisions for additional review.
Sensitive actions such as modifying payment details, sharing protected data, or approving transactions should trigger step-up authentication or human review. The agent can still perform the routine work, while a person remains responsible for decisions with significant business impact.
If the supplier record is changed incorrectly or sensitive information leaves the organization, the security team must reconstruct why it happened. The available logs may show plenty of activity while offering little explanation of the workflow that connected it.
Identity systems record the successful login, while network and endpoint tools capture connections, browser activity, and file movement. Application logs then show the vendor-record change and outgoing email. Together, these records document the individual events without revealing how webpage content influenced the agent, led it to retrieve internal data, and pushed the workflow outside its assigned purpose.
Investigators are left correlating timestamps, identities, application records, and network events across several systems. By the time they reconstruct the sequence, the agent may have completed many additional actions.
Runtime visibility gives security teams a connected record that follows the entire session. It can identify the agent, its human owner, the task it was assigned, the source content it encountered, the data it accessed, the applications it used, and the actions it took.
Session-level observability makes that context available while the workflow is still running. Security teams can enforce policy before risky actions are completed, investigate incidents with a clear chain of events, and use what they learn to refine future controls. The same record also gives governance teams concrete evidence of how agents operate across the enterprise.
The five gaps appear in different parts of the security program, but they share a common weakness: context is lost between the moment an agent receives access and the moment it takes action. Identity controls may approve the account, web controls may approve the destination, and application policies may permit the transaction. None of those decisions can remain reliable if the agent’s purpose, inputs, or behavior changes midway through the workflow.
The session provides the context needed to connect those decisions. Within it, security can isolate untrusted material before it redirects the agent, preserve ownership as work moves between people and agents, and protect sensitive values without stripping away useful business context. Task-level restrictions and approval gates keep actions within scope, while end-to-end observability records how the workflow developed.
Runtime security adds this continuous context to existing investments in Endpoint Detection and Response (EDR), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), and identity. Those systems continue protecting the layers they were designed to cover, while session-level controls govern what happens after access is granted.
Menlo Agent Runtime Security provides that control layer across browser-based agent workflows. Supported by AI Adaptive DLP and Menlo File Security, MARS is able to govern how agents interact with applications, data, web content, and files throughout the workflow.
Enterprise agents retain the access and information required to perform useful work, while security teams apply consistent policy across the workflow. Sensitive data remains protected, and people stay responsible for decisions that require business judgment.
AI governance becomes practical when policy stays with the agent throughout the workflow. Approved applications and relevant data remain available, while session controls govern which content the agent can trust, how it can use information, and which actions it can take.
When an exception arises or a decision carries significant business impact, a person receives the context needed to decide how the work should proceed. Menlo connects identity, endpoint, web, application, and data controls within the browser session, giving organizations consistent enforcement and clear ownership as agent use expands.
Request a Demo Today to see how MARS keeps policy active from access through action.
Menlo Security
