Why we didn’t build another chatbot and why security forced us to rethink OS-level AI agents

Over the last year, almost every AI product discussion starts the same way:

“So… what kind of Agent are you building?”

The short answer is: we’re not.

At NeuralLead, we’re building Vector, an AI system that operates at OS level, interacting with real software instead of generating suggestions or explanations.
That choice came with an uncomfortable realization very early on:
once an AI can act, security stops being a feature and becomes the architecture.

From chatbots to operators
Chatbots are great at explaining how to do things.
They’re terrible at actually doing them.
Vector was designed around a different idea,from a single high-level instruction, the system can:

• navigate the browser
• open and interact with real desktop applications
• create and edit documents
• move files
• execute multi-step workflows across tools
• No predefined RPA scripts.
• No brittle macros.
• No demo-only environments.

But this immediately raises a harder question.

OS-level autonomy is powerfuland dangerous
If an AI can operate your computer, then it can also:

• delete the wrong file
• leak credentials
• execute unintended actions
• amplify a single bad instruction into real damage
• This isn’t hypothetical.

Recently, agentic systems like Clawbot sparked serious concern in the community due to security vulnerabilities:

• overly broad system privileges
• exposed control interfaces
• prompt-injection leading to unsafe actions
• lack of proper isolation between agent and host

The core issue wasn’t “bad AI”.

It was unchecked autonomy running too close to the system.
That was the exact failure mode we wanted to avoid. How Vector approaches security differently, instead of letting the agent operate directly on the host system, Vector runs inside a secure container by design.

This wasn’t an add-on.
It became the foundation.

1. Secure container boundaries
   All execution happens inside an isolated, containerized environment:
   least-privilege by default explicit access scopes no implicit access to host credentials or filesystem controlled network exposure
   Even if something goes wrong, the blast radius is limited.

2. Permissioned action model
   Vector doesn’t “do whatever it can”.

Every meaningful action is checked against:

• an explicit permission model
• contextual constraints
• execution policies
• High-risk operations (destructive actions, sensitive data access)

can:

1. require confirmation
2. be blocked entirely
3. or remain human-in-the-loop

4. Autonomy without boundaries is just risk at scale.

5. Failure recovery over cleverness
   One of the biggest problems with early autonomous agents is that failure states are undefined.
   Vector is designed around:

• partial execution handling
• rollback and safe retries
• predictable state transitions

The goal isn’t to be impressive, it’s to be recoverable.

We’d rather build something that:
fails safely
can be reasoned about
and earns trust over time
instead of something that looks magical until it breaks.

Where we’re at

We’ve published a short public overview of Vector here:
👉 https://www.neurallead.com/vector/
We’re still early, and we don’t pretend to have all the answers.

If you’re working on:
autonomous agents
RPA beyond scripts
secure execution environments
human-in-the-loop systems
I’d genuinely love to hear:
what you think we’re underestimating
what you’d never trust an OS-level agent to do
where you think the real boundary should be