What Is a CASB? Cloud Access Security Brokers Explained

API mode connects to a sanctioned cloud service through the service's own administrative interface, with no traffic passing through the broker at all. It can inspect everything already stored in the tenant, find files shared with external parties, apply classification and data policy retroactively, revoke a share, quarantine a file, and see activity that never crossed the corporate network — including access from an unmanaged home computer. Its limitation is timing: it acts after the fact, and how quickly depends on the provider's notification and rate limits, which means minutes rather than milliseconds, and occasionally longer under load.

Forward proxy mode routes user traffic through the broker on the way out, either by steering from an agent on the device or through a gateway. It sees and can block in real time, and it covers services the organization has no administrative relationship with — which is the only way to enforce anything on an unsanctioned application. It also only sees devices that are steered through it, which in practice means managed devices, and it depends on TLS inspection to see inside the traffic.

Reverse proxy mode inserts the broker in front of a sanctioned application by redirecting through the identity provider at sign-in, so sessions from any device — including personal ones with no agent — pass through it. That makes it the standard answer for contractor and bring-your-own-device access to a corporate suite. It is also the most fragile mode: it works by rewriting URLs in the application's responses, and rich clients, mobile apps and applications that change their front end without warning are a known source of breakage. Log-collection mode is the fourth and simplest: ingest logs from firewalls, proxies and gateways to discover what is being used, with no enforcement at all.

The first thing most brokers are switched on for is finding out what is in use. Logs from egress devices are matched against a catalog of thousands of known cloud services, producing a list of every application anyone has touched, how much data moved, and how many people use each one. The list is always longer than expected, and the first run of it is usually the moment the program gets its budget.

The catalog is the part that carries the judgment. Each service is scored against attributes an organization would otherwise have to research individually — where the provider is based, what certifications it holds, whether it supports single sign-on and audit logging, what its terms say about ownership of uploaded content, whether it has a public breach history. That turns an unmanageable list into a triage exercise: sanction and manage, restrict to read-only, block, or leave alone.

Two cautions apply to the output. The first is that a discovery report describes what was seen from the paths that were logged, so services reached from unmanaged devices or off-network are underrepresented, and a low number is not the same as a low count. The second is political rather than technical: a shadow IT report names departments as much as it names applications, and the departments in question usually adopted those tools because something they needed was missing. A discovery program that arrives as an enforcement action generates workarounds; one that arrives with a route to getting a service sanctioned generates a shorter list next quarter.

Once a service is sanctioned, the broker's job shifts to what happens inside it. The recurring controls are sharing governance — finding and remediating links shared publicly or with external domains, and preventing new ones by policy — data inspection against the same classification rules a data loss prevention program uses, and download restrictions conditioned on device state, so a managed laptop can pull a file down and an unmanaged one can only view it in the browser.

One control worth naming specifically is tenant restriction: allowing sign-in only to the organization's own instance of a service, so a corporate device cannot authenticate into a personal or third-party tenant of the same platform and move data across the boundary that way. It closes an exfiltration path that looks like ordinary sanctioned traffic to every other control in the stack, and it is often the highest-value single policy a broker enforces.

Encryption and tokenization of fields before they reach the provider is offered by some products, and it deserves a warning rather than a recommendation. It genuinely keeps plaintext away from the service, and it also breaks the features the service performs on that data — search, sorting, deduplication, server-side processing and often the mobile client. It suits a narrow set of fields under a specific regulatory obligation and suits almost nothing else, and it should be tested against real workflows before anyone commits to it in a design.

Because the broker sees authentication and file activity across services, it can detect patterns that no single application would flag. Impossible travel between two sign-ins, a sudden bulk download by an account that normally reads a handful of files, a mass sharing event, a new administrative grant, activity from a location or an autonomous system the organization has never used before, or the distinctive pattern of a compromised account being used to distribute malicious links internally.

These are behavioral detections and they carry the usual caveat: they are correlations, and a legitimate migration project looks a great deal like an exfiltration. The output belongs in the same queue as other security detections rather than in its own console, which is one of the practical arguments for buying the capability inside a platform that already feeds a security operations workflow.

The neighboring capability worth separating is cloud security posture management, which looks at the configuration of cloud infrastructure — storage left public, over-broad identity permissions, logging switched off — rather than at user activity in software-as-a-service. The two are frequently sold together and answer different questions: one asks whether the environment is built safely, the other asks what people are doing in it.

The overlaps are real and worth mapping deliberately. A secure web gateway filters outbound web traffic by category and reputation; a broker understands the application semantics behind that traffic — not just that someone reached a storage service, but that they uploaded a file with a particular classification to an externally shared folder. Data loss prevention supplies the detection rules the broker applies inside cloud services, and covers the endpoint and email channels a broker does not. Zero-trust network access handles reaching private applications rather than public ones. Identity and conditional access decide who may authenticate at all.

Set against those, the boundary of a broker is fairly clean. It does not see local endpoint actions such as copying to a USB drive or printing. It does not govern private applications hosted in a data center. It does not replace the security controls the software-as-a-service provider operates, and it does not make an unsuitable service suitable. And in API mode it is not an inline control, so it should not be positioned to a stakeholder as something that prevents an upload — it detects and remediates one.

Which points at the honest question in most evaluations: whether the native controls of the suite already in use are enough. For an organization living almost entirely in one vendor's cloud, that vendor's own administrative controls cover a great deal of this, and a broker adds most value across multiple services, for unsanctioned application discovery, and for unmanaged-device access. Where several major services are in use, or where regulated data sits in a service whose native controls are thin, the broker is doing work nothing else does.

For government buyers there are two authorization questions rather than one. The cloud services being governed need to be appropriate for the data they hold, which for federal use generally means a FedRAMP authorization at the right impact level and, for certain categories, a government-community environment rather than the commercial one. Separately, the broker itself is a cloud service that will process the organization's traffic and metadata, so its own authorization status matters — and within one vendor's platform the broker module and the web gateway are not always authorized together.

Where Controlled Unclassified Information is involved, the broker becomes one of the more demonstrable controls in an assessment. It can show which services hold the data, who has access, what is shared externally and what was blocked, which is exactly the kind of evidence a NIST SP 800-171 or CMMC assessment asks for around the boundary. Tenant restriction earns its place here too, since it prevents the simplest route by which regulated material walks from an authorized tenant into an unauthorized one.

Finally, treat data residency and log retention as procurement questions rather than technical settings. Where the broker stores activity logs, how long it keeps them, whether they can be exported into the organization's own retention system, and what jurisdiction they sit in are all matters that are straightforward to answer during an evaluation and awkward to change once a platform is carrying production traffic.