What Is CASB?

A cloud access security broker is a product category: an enforcement point positioned between your users and the cloud services they use, so that policy can be applied to traffic and data the organisation does not host. The broader discipline it serves is covered in cloud access security.

It exists because the perimeter stopped containing the data. Once staff use dozens of cloud applications from unmanaged networks and personal devices, a control point that only sees corporate network traffic sees very little of what matters.

The two deployment modes decide what you can do

API mode connects to sanctioned applications through their own interfaces. It sees data already in the service, can scan it retrospectively, and applies to activity regardless of device or network. What it cannot do is block anything in real time — it observes after the fact and remediates.

Proxy mode sits in the traffic path and can block, redirect or modify requests as they happen. It offers genuine real-time control and brings the usual costs of being in-line: latency, breakage when an application changes, and the awkward fact that traffic can bypass it entirely from an unmanaged device.

Most deployments end up using both — API mode for depth across sanctioned applications, proxy mode narrowly where real-time blocking genuinely matters.

Shadow discovery is often the real return

Before any policy enforcement, a broker analysing network and proxy logs produces a list of the cloud services actually in use. That list is invariably several times longer than the approved one, and it is the most immediately useful thing the tool produces.

It is also how organisations discover where their data has been going — including, increasingly, which AI services staff have been pasting material into. See shadow AI, where the same discovery problem appears in a newer form.

Sanctioned, tolerated and blocked

The useful mental model is three categories rather than two. Sanctioned services are integrated, monitored and governed. Blocked services are genuinely unacceptable — a short list, because a long one gets routed around.

The interesting category is the middle one: services people clearly need, which the organisation has not formally adopted. Treating everything unsanctioned as blocked pushes that activity onto personal devices and out of view entirely, which is worse than governing it.

A tolerated tier — permitted, monitored, with data-handling limits — keeps the activity visible while the adoption decision is made properly. It also surfaces genuine demand: a service used by two hundred people is telling you something the procurement process has not.

Data controls are where these deployments most often overreach. Content inspection across every sanctioned service sounds comprehensive and generates enormous false positive volume. Starting with a narrow definition of genuinely sensitive content, in the two or three services that actually hold it, produces something the team can act on rather than another queue nobody reads.

Where to start

Run discovery before buying anything else. Knowing which services hold your data, and how many of them nobody approved, will change what you decide to enforce and in which order.

See cloud security best practices. GuardsArm runs cloud security assessments.