ABAC in collaboration: the last mile of Zero Trust

How Rocket.Chat and Virtru close the security gap in classified collaboration with attribute-based access control (ABAC).

In a classified operation, the person who had access to a room when they joined it may not be the person who is authorized to be there right now. Clearances change. Program assignments change. People rotate on and off missions, on base and off base, sometimes overnight. When access is decided once, at join time, and never checked again, that gap is where sensitive information quietly reaches someone who is no longer cleared to see it.

That gap is the subject of the latest episode of Hash It Out, Virtru's data-security podcast. Rocket.Chat's chief product officer and chief commercial officer, Chris Skelly, and Virtru product manager JP Ayyappan sat down to talk through how attribute-based access control closes it at the collaboration layer.

Join-time access is not real-time authorization

The core idea is simple: authorization has to be continuous. A decision made at one moment can be wrong a minute later. So the real question is never "was this person allowed in when they joined?" It is "does this subject have the authority to access this object, with these attributes, at this exact moment?"

In the partnership, Rocket.Chat and Virtru split that question cleanly. Rocket.Chat is the policy enforcement point. Virtru is the policy decision point, and the single place policy lives.

"Every time an individual operating within Rocket.Chat is trying to access a particular resource, a room, a file, we make a call to Virtru and essentially say, does this person have the authority to access an object with these selected attributes? If the answer is yes, we let them in. If the answer is no, we don't ask why. We simply deny the access."
~Chris Skelly, Rocket.Chat

One control plane, not one policy per app

The value of that separation shows up the moment an organization runs more than one tool. Nobody wants to write an access policy for chat, then rewrite it for email, then rewrite it again for file sharing. Attribute-based access control in collaboration only holds up at scale when policy is defined once and every system asks the same source.

"Customers don't want to create policy that applies only to Rocket.Chat, and then a copy of that for email, and a copy for SharePoint. They want one pane of glass for managing policy for access to data in general."
~JP Ayyappan, Virtru

Rocket.Chat sends Virtru the user's ID, the resource ID, and the required attributes, and gets back a yes or a no. Policy administration stays consistent across every application, and Rocket.Chat never has to store attributes that were never its to hold.

Security that removes friction instead of adding it

There is an old assumption that more security means more friction. At the collaboration layer, the opposite happens. When everyone in a room can trust that every other participant is authorized right now, uncertainty drops. Rocket.Chat even re-checks membership before anything is posted: as attributes change, it polls and updates the room, so a commander posting to a hundred people never has to wonder whether ten of them rolled off the program overnight.

That confidence is what lets different programs, units, and coalition partners work in one space instead of standing up a separate workspace for every combination of clearances.

"ABAC continuous evaluation of access actually enables those conversations. Those barriers are now coming down, because you can more easily manage a group of people with heterogeneous credentials all within the same environment, knowing the data is continuously protected."
~ Chris Skelly, Rocket.Chat

For national-security teams, the practical payoff is speed. Changing one attribute on a person's entitlement can grant the right access instantly, collapsing work that used to take weeks of paperwork into minutes, as long as the discipline of tagging resources correctly is in place. For armed forces and intelligence customers, that discipline is already part of the job.

And when the "user" is an AI agent

AI raises the stakes, because an agent with access will consume everything it can reach, fast. The partnership treats an agent the same way it treats a person: as an entity that only gets in if its attributes allow it.

"We treat all entities the same. It doesn't matter if it is an agent or a person. As long as you have the right entitlements and attributes, you get access. Otherwise, access is completely denied. It is proactive. It's like we operate a door up front, before you can get in."
~ JP Ayyappan, Virtru

In Rocket.Chat, an agent built with the Agent Development Kit acts as a proxy for a user, so every action it takes is governed by that user's attributes, and nothing more. Access is decided at the door, not audited after the fact.

Built for the missions that can't get this wrong

This is aimed squarely at the organizations Rocket.Chat is built for: defense, intelligence, and critical infrastructure teams running in air-gapped and isolated networks, and public-sector and enterprise organizations that demand digital sovereignty and full control of their own infrastructure. 

Because Rocket.Chat is open source and deploys anywhere, and Virtru provides the attribute-based decision layer, those teams get continuous, provable, real-time authorization without giving up control of where their data lives.

Or, as the Rocket.Chat line that opened the conversation puts it: security has to be proven, not promised. Access should reflect who someone is right now, and every claim should be backed by evidence.

Watch the full episode

Chris and JP go deeper on mapping classifications across coalitions, need-to-know attributes, and what both teams are building next. Watch the full Hash It Out episode with Rocket.Chat and Virtru: The Last Mile of Zero Trust: Governing the Collaboration Layer.