agentura.

OS-level isolation, need-to-know by design

Written by

in

When your agents handle real customer data, “we take security seriously” isn’t an answer. The architecture is.

One company, one isolated environment

On Agentura, every company runs inside its own OS-isolated environment, enforced by the Linux kernel. That means a dedicated per-company Linux user with a private 0700 home directory, a per-company private network, and every Linux capability dropped by default. Your agents live in their own walled-off slice of the system, not in a shared pool where one tenant’s process can quietly read another’s.

The point of this design is what happens in the worst case. Even if an attacker reached container-root inside one company’s environment, Unix file permissions still block them from listing — let alone reading — another company’s data, the dropped capabilities stop them mounting filesystems or escalating, and the private network gives them no path to anyone else. Crossing the boundary would take a kernel-level or Docker-daemon escape, not a misconfigured policy. Separation isn’t something you trust someone to enforce — it’s enforced by the operating system itself.

Strong separation, without the VM tax

The classic way to isolate tenants is to give each one a full virtual machine. It works, but it’s heavy: slow to start, expensive to run, and wasteful when most of that VM sits idle. Agentura draws its boundaries a different way — per-company UIDs, private networks, and dropped capabilities, all enforced by the shared host kernel — so you get hard, OS-level separation between companies at the density and speed of containers, without paying for a fleet of per-tenant virtual machines.

The strongest security boundary is the one an attacker can’t talk their way around. A dropped capability doesn’t make exceptions.

Need-to-know, by design

Isolation keeps companies apart. Need-to-know access control keeps things tidy inside your company too. Each agent only sees the data and the tools you explicitly grant it — and a connector that isn’t granted is never even registered as a tool the agent could call.

That gives you real control over your own AI workforce:

  • Grant a support agent your customer conversations while withholding the billing connectors — a denied tool is refused at the call gate, not just hidden.
  • A back-office agent gets the connectors it needs for its job and none of the others.
  • New projects start with no connectors and no data; access is something you link, on purpose — not a default everyone inherits.

The result is a system where blast radius is small by construction. Every agent operates with the access you chose for it, so a mistake or a bad instruction is contained, not catastrophic.

Security you can reason about

Good security isn’t a long list of features — it’s a model you can actually hold in your head. Companies are isolated at the operating-system level. Agents are scoped to what you grant. Capabilities start at zero and are added deliberately. When the architecture is this explicit, you can give your customers a clear, honest answer about how their data is kept apart — because the answer is built into how the platform runs.

See how Agentura keeps your data isolated →

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *