How we turn customer security requirements into features that unlock coverage

In an enterprise account, the thing that decides how much of a customer's traffic our agent can actually handle is usually their security standard. The model is rarely what holds it back. If a customer's compliance team will not let the agent touch a certain kind of data, then every conversation built around that data sits outside what we can cover, no matter how capable the underlying platform is.

At Notch, this is where a lot of the real work happens, and it is the center of what our delivery and solutions team does. A customer describes a security requirement, and that requirement quietly draws the line around the agent's coverage. Our job is to turn the requirement into a feature that meets their standard exactly, so the line moves and the coverage opens up. We think of this as a coverage-first way of working, starting from how much of the customer's traffic the agent can safely carry and treating every requirement as something standing between us and a higher number. File sanitization (CDR) is the clearest example to walk through, and it is a good stand-in for how the team approaches this kind of work in general.

The request that looked like a blocker

One of our enterprise financial services customers operates under strict security standards for how files are handled. Their policy was clear. No file that arrives from an end user gets analyzed until it has been cleared through their own security process first. This is a completely reasonable position for a regulated company to take. An attachment from an unknown end user is exactly the kind of thing a security team worries about, and they were not going to make an exception because an AI agent was the thing reading it.

For us, that meant a real gap. The agent could handle any conversation that stayed in text. The moment a customer sent a photo or a document, the agent had nothing to work with. It could not analyze the image, so it could not resolve anything that depended on the image. In practice that took a whole category of conversations off the table. Every case where a person naturally sends a picture instead of typing a description was a case the agent could not finish on its own.

It would have been easy to treat this as a limitation to explain away. We could have told the customer that image handling was out of scope for their environment and moved on. That is the wrong instinct, and it is the opposite of how the team works. The requirement was not a reason to shrink what the agent could do. It was a spec for a feature we had not built yet.

Coverage in regulated accounts is a compliance problem before it is a model problem

This is worth being direct about, because it changes how the team plans the work. In a regulated account, raising the agent's coverage is often less about improving the model and more about clearing the compliance conditions that gate a given workflow. The customer already believes the agent can read an image. What they need to know is that reading it will not break their security posture. Most of the hard parts of deploying AI in a regulated environment live right here.

So when a customer hands the team a security requirement, we read it as a list of the features that stand between us and a higher coverage rate. Each requirement is a door. Behind each door is a set of conversations the agent could already handle if the door were open. The engineering work is building the key that their security team will accept. Then the door opens, and the coverage that was always technically possible becomes real.

Attachment handling was one of those doors. The agent was ready to analyze images. The customer's file-security standard was the lock.

What we actually built

The feature the team built is what we call file washing. The idea is simple to describe and the discipline is in the details. Before the agent analyzes any file a customer sends, we route that file through the customer's own scanning service. The file gets checked against their security standard, the same way any other file entering their systems would be checked. Only after it comes back clean does the agent get to look at it and use it.

This order matters. We did not build our own parallel scanning system and ask the customer to trust it. We sent the file to the service they already run and already trust, so the check happens under their standard, with their tools, inside their control. When the file clears, we know it cleared by the customer's own definition of clean, not ours. That is the part that makes a security team comfortable. We are not asking them to accept a new thing. We are fitting into the process they already believe in.

The team also had to decide what happens when a file does not pass. If the scan fails, the agent does not quietly drop the conversation or guess at what the image might have been. It asks the person to send a new image. That keeps the conversation moving and keeps the person in control, and it means a single bad file does not turn into a dead end. From the customer's point of view, a failed scan gets handled cleanly and safely rather than becoming an error nobody sees.

Building for the standard, not around it

Security and compliance are not obstacles to work around at Notch. They are the starting point. So when a hard requirement comes in, the question is never how little we can do to get past it. It is how to build the thing that meets the standard fully, because anything less is not something the team would ship into a regulated account, and it would not survive a customer whose whole job is to look closely.

The team built file washing to meet the standard head on. The file goes where their policy says it has to go, gets checked the way their policy says it has to be checked, and only then does the agent proceed. There is no shortcut hidden in the middle. When their security team reviewed how it worked, there was nothing to argue about, because the design followed their own rules rather than trying to reinterpret them.

That is a deliberate choice about how Notch spends engineering time. A workaround that sidesteps a requirement is usually faster in the first week and slower over the life of the account, because every review, every audit, and every new workflow reopens the same question. Building to the standard is a little more work upfront and then it stays solved. Once file sanitization was in place, image handling stopped being a special case that needed defending. It was just part of how the account worked, cleared under the customer's own security process.

What it unlocked

The result is straightforward. Any attachment a customer sends is now analyzed. A person can send a photo instead of describing something in words, and the agent can work with the document directly, because the file has already been cleared under the customer's security standard before it reaches the point of analysis.

That opened up the whole set of conversations that had been stuck before. Cases that depend on someone sending an image are now inside what the agent can handle end to end, in an environment where that was not possible a short time earlier. The coverage rate went up, and it went up not because the agent got smarter about images but because the team removed the compliance condition that was keeping it from using an ability it already had.

This is the payoff that matters. Coverage is the number that tells a customer how much of their real traffic the agent is carrying. Every feature like this one pushes that number up in a way that survives a security review, which is the only way it counts in a regulated account.

Why building the feature was faster than the workaround

There is an operations argument here too, and it is the reason the team leans toward building the real feature quickly rather than sitting on a request. A blocked workflow does not just sit still. It generates conversations that fall back to a person, questions about when it will be supported, and repeated one-off explanations for why the agent cannot do the obvious thing. All of that is slow, and all of it is friction the customer feels every day.

Shipping the compliant feature ends that friction in one move. Once file washing was live, nobody had to route image conversations around the agent, nobody had to explain the gap, and the customer stopped hitting a wall on a very common kind of message. The team moves faster because the exception is gone. The customer's own operations move faster because a whole class of requests now resolves without a detour. Building the feature was the fast path, not the slow one, and that is usually true even when it does not feel that way in the first week.

How the coverage-first approach scales to the next request

file sanitization is one instance of a pattern the team runs on every account. When a customer describes something their compliance team needs, we try to name, early, exactly which conversations that requirement is currently keeping the agent away from. That turns a vague security discussion into a concrete coverage target, and it tells us what shipping the feature will actually be worth.

Then we build to their standard, using the customer's own systems where we can, so the feature clears review the first time. Custom authentication so the agent can verify a customer's chat under the account's own rules. Deploying into a customer's own cloud when their security posture requires it. Connecting to a new system the customer already runs so the agent can act inside it. These look like different projects, and under the surface they are the same move. Take the requirement seriously, build the feature that satisfies it exactly, and watch a set of conversations that were off-limits become part of what the agent covers.

The features that raise coverage are almost never the flashy ones. They are the ones that let the agent operate inside a customer's real security world instead of a simplified version of it. file sanitization is a small feature by most measures. It also turned every image a customer sends from a dead end into something the agent can handle, and that is exactly the kind of work the team at Notch is built to do.

‍