Blocking an AI website does not stop an employee or an AI agent from reaching company SaaS data through approved APIs, delegated authorization, or desktop applications. Security controls need to govern the actions an identity can take across those paths, including when an agent acts with that identity’s permissions.
The control gap sits behind the browser block
A browser block answers a narrow question: can this device load this website? It does not answer whether an agent can call a SaaS API, use an existing OAuth grant, or act through a connected application.
That difference matters because authorization follows the identity and its granted scopes. If an employee has connected an AI tool to a workspace, CRM, file store, or ticketing system, the connection may continue to work without the employee visiting the AI provider’s site from a managed browser. An agent can receive a task elsewhere, then read, search, create, update, or share data through the permissions already delegated to it.
The result is a familiar security failure mode. The visible interface gets treated as the control point while the useful work happens through an integration path that was never examined with the same care.
The supplied event context describes Akamai repositioning its former LayerX product around interaction-level protection for employees and AI agents across browsers, SaaS, and desktop applications. That positioning reflects the broader problem: an AI agent’s risk cannot be understood solely from the tab it opens. Teams need visibility into the action, the data involved, the identity behind it, and the destination.
Delegated authorization changes the risk model
Delegated authorization is valuable because it lets people connect tools without handing over passwords. It also creates durable access paths that can be easy to forget.
A connected agent may have permission to inspect cloud files, pull customer records, post messages, create support tickets, or update calendar events. Those actions can be legitimate. The risk appears when the original approval was broad, the purpose changes, ownership becomes unclear, or the agent is prompted into an action the employee did not anticipate.
The key question is not simply, “Was this AI tool approved?” Ask more precise questions:
- Which identities have delegated access to which SaaS systems?
- Which scopes allow reading sensitive data, changing records, or sending information outside the company?
- Can the authorization be revoked quickly when the tool, employee role, or security posture changes?
- Is there an audit trail that shows the agent’s action and the authorization path that enabled it?
This is the same lesson behind The Key Changed Without a Warning: access that works today can become a security liability when the conditions around it change quietly.
Protect the interaction, not only the destination
Interaction-level protection means evaluating what happens at the point of use. A destination block may stop access to one site. It cannot tell a security team whether a user copied customer data from a desktop app, approved an overly broad SaaS connection, or instructed an agent to export information through an API.
Start by mapping AI-related access already present in the environment. Include browser extensions, desktop clients, SaaS marketplace integrations, OAuth applications, service accounts, automation platforms, and internal agents. The inventory should name an accountable owner, the connected systems, granted scopes, the data classes involved, and a review date.
Then separate low-risk assistance from high-impact actions. Drafting a document from non-sensitive material has a different risk profile from searching a shared drive, changing payment information, or sending a message to an external recipient. Those categories need different controls, approval paths, and monitoring.
Least-privilege access is practical here. Give an agent the smallest set of permissions required for a defined task. Prefer short-lived access where the system supports it. Require additional confirmation for irreversible or external actions. Review existing grants on a schedule, especially after an employee changes roles or a vendor changes its product behavior.
Make agent activity reviewable by people
An AI agent can complete several API calls faster than a person can switch between tabs. That speed raises the value of clear logs and meaningful alerts. A security team should be able to reconstruct what was requested, which identity acted, which tools were used, what data was accessed, and where the result went.
Avoid treating every unusual action as malicious. Overly noisy controls get bypassed or ignored. Focus review on combinations that create material exposure: broad scopes paired with sensitive data, new external destinations, high-volume exports, permission changes, or actions taken outside normal working patterns.
The operational goal is simple: make safe uses easy to approve and risky uses hard to complete silently. When an employee connects a new agent to a SaaS tool, the approval flow should surface the access being granted in plain language. When that agent later attempts an action outside its expected role, the organization should have a way to pause, inspect, and revoke access before the action becomes an incident.
A browser block can remain one useful control. It should sit inside a wider system that follows identities, permissions, data movement, and agent actions wherever they occur.
Sources
Akamai, supplied current-event context: former LayerX product repositioned for interaction-level protection across browsers, SaaS, and desktop applications.
Comments
No comments yet.