When your agents handle real customer data, “we take security seriously” isn’t an answer. The architecture is.<\/p>\n
On Agentura, every company runs inside its own OS-isolated environment<\/strong>, enforced by the Linux kernel. That means a dedicated per-company Linux user<\/strong> with a private 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 \u2014 let alone reading \u2014 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 \u2014 it’s enforced by the operating system itself.<\/p>\n 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 \u2014 per-company UIDs, private networks, and dropped capabilities, all enforced by the shared host kernel \u2014 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.<\/p>\n The strongest security boundary is the one an attacker can’t talk their way around. A dropped capability doesn’t make exceptions.<\/p>\n<\/blockquote>\n Isolation keeps companies apart. Need-to-know access control<\/strong> keeps things tidy inside<\/em> your company too. Each agent only sees the data and the tools you explicitly grant it \u2014 and a connector that isn’t granted is never even registered as a tool the agent could call.<\/p>\n That gives you real control over your own AI workforce:<\/p>\n 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.<\/p>\n Good security isn’t a long list of features \u2014 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 \u2014 because the answer is built into how the platform runs.<\/p>\n0700<\/code> home directory, a per-company private network<\/strong>, and every Linux capability dropped<\/strong> 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.<\/p>\nStrong separation, without the VM tax<\/h2>\n
\n
Need-to-know, by design<\/h2>\n
\n
Security you can reason about<\/h2>\n