Industry Research
Most AI breaches start with missing access controls
IBM’s 2025 breach research found that the organizations hit by an AI-related incident almost never had AI-specific access controls. The takeaway isn’t “add a dashboard.” It’s that access control for AI does two jobs a logging tool doesn’t.
Read the finding carefully and it stops being a statistic about negligence. In nearly every case there was no layer governing what the AI could reach, and no layer inspecting what it sent back. The breach vector wasn’t a bug to patch — it was the intended behavior of the integration: an app serializes sensitive data into a prompt, or a tool hands a sensitive record back to a model, and nothing in between is allowed to say no.
“Access control for AI” is doing two things at once, and a logging layer does neither.
One: fail closed where a call touches data
On the paths where AI acts on data — an agent calling an MCP tool or another agent, or an MCP server you expose inbound — the safe default is the opposite of availability-first. A call BlueAspen can’t judge never reaches the data, and a misconfigured gateway refuses to start rather than wave traffic through. That is what access control has always meant everywhere else: when in doubt, deny.
(For employees browsing to AI apps, BlueAspen deliberately fails open — you never want a policy outage to block someone working. Opposite postures, on purpose, for opposite surfaces.)
Two: inspect what AI brings back
The half almost everyone misses is the result leg. A gateway can log that an agent called a tool; it rarely looks at what the tool returned. But the SSN, the card number, the patient record — the sensitive part is usually in the answer. BlueAspen screens the reply before the model, the agent, or the person sees it, and redacts regulated fields in place so the response stays valid and the work continues.
A logging / gateway layer
Routes and records what AI did.
- Logs the connection and the request
- Fails open — availability first
- Governs what was registered
- Tells you after the fact
BlueAspen
Inspects and controls what the data does.
- Validated detection on the result leg, redacted in place
- Fail-closed on ingress and agent-to-tool paths
- Discovers undeclared agents, MCP servers and AI use
- Acts inline, at the moment of the call
Audit-grade, not best-effort
Access control an auditor accepts can’t be a classifier’s hunch. BlueAspen runs the real validators — the Luhn checksum for cards, ABA for routing numbers, mod-97 for IBANs, Shannon entropy for secrets — across 60+ context-scored patterns, each finding carrying the rule that fired and why, tuned for low false-block. It detects PHI, PCI, PII and secrets and produces the record a reviewer asks for. (We don’t certify anyone against a framework; we give security and compliance teams the evidence and the control they were missing.)
On the data path, not bolted to the network edge
This isn’t an add-on to a firewall. It’s a purpose-built layer on the data path, in three shipped modes: an inbound MCP gateway that fronts the servers you expose (it passes the official MCP client SDK run against the reference server); an Agent Proxy for egress from the agents you run, across MCP tools, agent-to-agent and model calls; and an Employee Proxy — a TLS-inspecting forward proxy plus endpoint agent — for people using AI across 40 providers and roughly 6,000 AI domains. Twelve analyzers run on local ONNX models, so by default no customer data goes to a third-party LLM, and it complements the DLP, CASB and AI gateway you already run rather than replacing them.
Put access control where your AI touches data.
In 20 minutes we’ll walk the request leg, the result leg, and the evidence trail on a real call.