Moinul Khan, Co-Founder & CEO | Aurascape
September 23rd, 2026

Trusting AI with the work that matters

The more useful AI becomes, the more we will ask it to do with information we need to protect. A coding assistant, for example, can contribute more when it works with a company’s source code and understands the project well enough to help make changes. Giving it that access creates a responsibility to protect what the company has spent years building. That is the kind of decision I want security teams to be able to support with confidence.

When we started Aurascape, CIOs and CISOs were already describing this problem to me. Their companies wanted to use AI, and blocking an application was becoming a poor answer when AI was also appearing inside software their people depended on. They needed a way to protect data and prevent threats while allowing useful work to continue. I understood why they were frustrated. I had helped build the generation of security products they were relying on.

I thought about those conversations as I read Dario Amodei’s “We Must Pace the Frontier.” He argues that the leading AI labs should slow the growth of model capabilities enough for safety work to keep up. I agree with his central concern: our ability to control these systems needs to keep up with what they can do. The value of slowing down is giving the labs time to strengthen the safeguards around their models. Dario points to work such as improving monitoring and keeping AI systems within their intended boundaries. Companies deploying AI need to do that work in their own environments, too. 

Dario writes about AI’s potential to help cure major diseases. Realizing that promise will depend on institutions being willing to trust AI with consequential work. Building that confidence is a substantial engineering responsibility for the security industry. It is also the reason we started Aurascape.

Understanding AI interactions

Much of my career has been spent on network and data security, through the growth of the internet and then the cloud. Our industry built ways for companies to adopt technologies that changed where people worked and where their information lived. Those architectures took enormous effort, and they remain important. I know how much expertise went into them because I worked alongside the people building them.

With AI, I saw a requirement that deserved the same seriousness. An approved application could support many different activities, with very different consequences. A person might ask it to explain a public document, then upload confidential material in the same conversation. An agent could retrieve information from one business system and send it to another. Knowing that the connection was permitted would tell a security team very little about whether those particular exchanges should happen.

We had to understand the interaction itself: the information moving through it, the instructions being received, and the actions being taken. That meant going deeper than recognizing an application or its destination. The architecture had to let a security team permit useful activity within an application and intervene when a particular interaction put the company’s data or systems at risk.

Anthropic has published a particularly clear example of why this matters. In its account of agent containment, it describes a malicious file that instructed an agent to upload other workspace files using an attacker’s credentials. The upload went to Anthropic’s own service, a destination the application needed permission to reach. The destination check passed, and the files ended up in the attacker’s account. Anthropic addressed the problem by inspecting those requests and rejecting credentials that did not belong to the session. 

I appreciate the candor of that account. It gives the security industry something concrete to learn from. The difference between legitimate work and a data leak was inside the interaction with an approved service. That is precisely the depth at which enterprise policy needs to operate.

Why independent security matters

The cybersecurity evaluation incidents Anthropic disclosed this month illustrate a related point. Models were told they were in simulations, but misconfigured environments gave them access to the real internet, where they took harmful actions. These evaluations ran without the cyber safeguards included in released products, an important distinction. Even so, I take the lesson seriously: instructions about an environment and the limits enforced by that environment are separate responsibilities. 

The work to make models more dependable deserves serious investment. It also leaves decisions that belong to the enterprise. A model can follow a request faithfully and still send information somewhere the business does not permit. The hospital, bank, or software company has to decide what may be shared and what an agent is authorized to do. The AI lab cannot make those decisions on its behalf.

For me, this is the role of an independent AI security layer. It gives the business a place to enforce its own policy across the AI it uses, including when an agent misunderstands a task or follows a harmful instruction. The more responsibility we give AI, the more important it becomes for the enterprise to enforce its policies independently of the agent doing the work.

Building for prevention

At Aurascape, we committed to prevention from the beginning. That requires security to be in the path while the work happens, with the ability to stop an unsafe exchange before it reaches its destination. A record of a data leak is useful for investigating it, but the information has already left. As agents take more steps on their own, the opportunity for a person to notice and intervene becomes smaller. The architecture has to account for that.

Making that commitment meant taking on some hard engineering. We built a distributed inline proxy to inspect AI communications as they happen. Customers can add our endpoint agent when they need to discover AI applications and agents running on their devices. We also had to build the ability to decode what was happening within those communications.

Simply placing a security product in the traffic path does not mean it understands the full context of an AI interaction—or the actions that follow. Traditional security was built around understanding users, applications, and data. AI introduces a much richer and more dynamic context. To secure AI effectively, at Aurascape, we understand the user, delegation, user intent, prompts, responses, agents, tools, skills, and data—and correlate all of these elements across each active transaction in real time. This contextual understanding is what enables security to move beyond simply inspecting traffic to understanding what the user or agent is trying to do, what actions are being taken, and what data is involved.

AI makes this particularly demanding because an interaction can continue over time, stream information in both directions, and lead to further actions. Inspection has to preserve the working session. It has to be fast enough for people to keep using the tool productively. It also has to recognize sensitive information and threats in the context of the interaction, which means understanding and enforcing appropriate account types and licenses.

Putting ourselves in that path means accepting responsibility for the experience. If security disrupts an engineer’s work or breaks an agent’s session, that becomes a real problem. Reliability and performance belong in the same conversation as protection, and I am proud of our team’s willingness to take on that responsibility. It requires deep experience in networking, security, and AI, with engineers who understand what it takes to make those disciplines work together in a customer’s environment.

Starting Aurascape gave our team the freedom to build an AI-native architecture around those requirements, with prevention determining how the platform works. The product has to be able to act on what it understands, at the moment that understanding can still make a difference.

Consistent protection across AI tools

The architecture also has to work in an enterprise that uses AI in different places. An employee may use a commercial assistant while another team builds an internal application and developers run agents on their laptops. Over time, more work will pass between agents. I want our customers to retain a consistent way of protecting their information as those patterns change, without depending on a particular model provider to define its security policy.

This is why our mission centers on a foundational network security layer for AI interactions. The network connects people, applications, models, and tools across these environments. Understanding their exchanges creates an opportunity to apply the company’s policy as information moves between them. Endpoint security, identity controls, and application security remain essential parts of that protection. We are adding the depth needed for AI interactions alongside them.

Confidence to adopt AI

There is a practical benefit to this approach. A company can make a much more useful decision about AI when it can distinguish between activities within an application. It can allow an employee to work with an assistant while setting guardrails for riskier capabilities within that same application. It can give an agent access to a business system with limits on the actions it may take. Security teams gain a way to support adoption that reflects how the business intends to use the technology.

I judge the value of our work by our customers’ ability to put AI to use responsibly. Better protection should make a company more confident about expanding a useful deployment. It should help a security leader explain what is permitted, what is being stopped, and why the business can proceed safely. Those are outcomes a business can use to decide where AI belongs next.

Dario’s essay asks the industry to make room for the work that safe progress requires. I welcome that argument, and I see a clear responsibility for those of us building enterprise security. We have to build systems that businesses can depend on as they give AI more useful and demanding work. We should expect that responsibility to grow with the capabilities of the models.

I am a builder, and seeing the work become real is what keeps me going. An engineer shows me something new working, or a customer recognizes a capability they have been missing. Those moments reinforce why we started. We chose a difficult architecture because companies need protection that can operate where AI is doing the work. I want their security teams to have the confidence to support the next useful idea, and the means to make it safe enough to pursue.