This week, Box CEO Aaron Levie posted a set of predictions on X, and the core point is direct: agent swarms are going to be a core part of many enterprise workflows in the future. His reasoning is simple too, an agent swarm can take a problem that breaks down into multiple subtasks and throw compute at all of them in parallel, instead of working through them one at a time the way a human team has to. Cybersecurity sits at the top of the list of scenarios he expects to benefit, cyber will be one of the biggest beneficiaries, he said, because tracing an attack path is fundamentally a job that requires chaining together a large number of possible vulnerability scenarios to test, which suits an agent that doesn't get tired and can run many of those checks in parallel.
Token consumption becomes the new unit of security spend
The most concrete line in Levie's prediction is this: cybersecurity agent swarms will become one of the biggest token uses in large enterprises given the range of IT systems, software, physical infrastructure, and data that needs to be protected at all times. That's worth unpacking, it means security teams will soon need to budget for agent runtime cost, not just for security tool subscriptions. The old bottleneck in security work was headcount, how many attack chains a team could track at once depended on how many analysts it had. An agent swarm swaps that bottleneck out for compute and token budget, the number of attack surfaces you can track in parallel theoretically shifts from how many analysts you have to how much you're willing to spend running parallel tasks. That's a change in kind, not a modest efficiency bump. Levie's earlier prediction was that within five years, 90% of enterprise token consumption will be kicked off by no human at all, meaning enterprise security will mainly need to defend against machine-initiated behavior, not human-initiated behavior.
What agent swarms actually break isn't a firewall. It's an assumption
Levie made a sharper point in a conversation with a16z's Martin Casado, enterprise systems rest on an assumption that most people do the right thing nearly all the time, with deliberate misuse being vanishingly rare. That assumption underpins decades of enterprise access-control logic, give each employee the permissions they need, and leave the rest to trust plus the occasional audit. Agent swarms don't make deliberate misuse more common, what they change is a different variable, one the system was never actually defending against: the speed and scale at which errors can happen. A human employee's daily error count is naturally capped by how many actions they can physically perform in a day. An agent swarm can run the same category of action thousands of times in parallel within minutes. The permission model hasn't changed, but the throughput of potential mistakes has jumped by orders of magnitude, and that's the real exposure, not whether any single agent happens to be well built.
"Enterprise access control rests on the assumption that humans don't make mistakes at scale simultaneously. Agent swarms don't make deliberate misuse more likely, they remove a variable the system was never defending against: the speed limit on how fast errors can occur." — paraphrased from Aaron Levie's conversation with Martin Casado
a16z podcast conversation
Security and productivity are two sides of the same permission problem
Levie also names a tension that often gets avoided: security and productivity gains are inexorably linked in the AI era, not two things you can optimize separately. An agent needs enough information access to actually move productivity forward, but the wider that access gets, the bigger the blast radius if it misjudges something or gets misused, and locking everything down completely kills the productivity gain AI was supposed to deliver in the first place. This isn't something a stricter approval process alone can fix, because the approval process itself has to keep pace with how fast an agent executes, if every step needs manual sign-off, an agent swarm's parallel advantage just gets dragged back down to human speed by the approval step. The more sustainable fix is probably finer-grained permissions, an agent only ever sees the narrow slice of data it actually needs, paired with solid logging, every action traceable to exactly which agent did it and under what instruction, rather than treating access as a simple on-or-off switch.
This logic is usable right now for small teams, no need to wait for swarm scale
Most small and mid-sized teams aren't running hundreds or thousands of agents in parallel yet, but the permission problem Levie is pointing at already exists with just three or four agents. A customer-service agent that can read the ticketing system, a finance agent that can call the invoicing API, each reasonable on its own, and if the permissions aren't designed finely enough, it's just as hard to tell which link in the chain caused a problem when something goes wrong. Rather than waiting until scale forces the governance question, it's cheaper to treat each avatar's permission boundary and action log as baseline configuration from day one, not a patch applied after the fact. That's part of why a platform like KarmaBox builds independent memory and permissions per avatar, with every call leaving a trace, as a foundational design choice rather than leaving users to manage dozens of scattered API keys themselves. Laying that foundation before you're anywhere near swarm scale costs a lot less than tearing things down and rebuilding once scale actually arrives.
