An inside look at the architecture behind Computer AirSync and why getting permissions right is the foundation for secure, AI-powered work.
Every company we talk to has the same problem, whether they know it or not. They’ve adopted a dozen best-in-class tools – Jira for engineering, Salesforce for sales, Google Drive for docs – and each one has its own intricate web of permissions controlling who sees what. When they start connecting those tools to an AI like Computer, that web doesn’t come with them. The data moves. The access controls don’t.
The result is a silent security gap: a system where the AI can, in theory, surface anything to anyone — regardless of what the source system intended. For enterprise buyers, that’s not a productivity tool. That’s a risk they won’t accept.
Here’s how we closed it.
1. Introduction: The silent security gap in a multi-tool world
Every engineer has a pet problem they’re obsessed with. Mine was the silent, ticking time bomb of permission drift. And at DevRev, it wasn’t abstract — it was a direct threat to the thing we’re selling.
Our Land motion is simple: get Computer into a new account fast, by delivering immediate time-to-value for Support Teams or Sales Teams. But that motion breaks down the moment a buyer asks: “If we connect our Jira, our Salesforce, our Google Drive – who can see what?” Without a credible answer, there is no Land.
We were building a platform designed to unify work across dozens of specialised tools. We were syncing the data perfectly. But the access rights were a house of cards.
When you import data from one system to another, the intricate web of permissions who can see what, who can edit what – is typically left behind. This forces a productivity-killing choice: either spend countless hours manually recreating permissions (a process riddled with human error), or accept a massive security vulnerability. For companies adopting AI that needs to safely access and reason over combined data, this isn’t a minor inconvenience. It’s a blocker.
At DevRev, we recognised that solving this couldn’t be an afterthought. It had to be a foundational piece of our architecture – because without it, Computer can’t be trusted, and if Computer can’t be trusted, we don’t Land.
2. The core problem: Why “permission drift” is more than an annoyance
Managing permissions across disparate systems introduces three critical challenges – and each one is a potential objection in a sales cycle:
- Manual overhead. When data is imported into a new system, administrators are typically forced to reconfigure permissions from scratch. It is labour-intensive, tedious, and error-prone. A single mistake can block necessary access or, worse, grant it to the wrong person. No security-conscious buyer will accept this.
- Permission drift. This is the subtle but dangerous phenomenon where access rights in source and destination systems diverge over time. An employee leaves a project and their access is revoked in Jira — but it remains active in the secondary system. Over time, small discrepancies accumulate into unpredictable security holes and compliance nightmares. For enterprise accounts, this is a deal-killer.
- Security and compliance exposure. Getting permissions wrong risks exposing sensitive data – financial projections, unannounced product features, customer PII – to users who should not see it. This exposure can happen directly, or indirectly through secondary systems like enterprise search and generative AI tools that index improperly secured data. This is precisely the attack surface that Computer operates in. If Computer can surface anything to anyone, it is not a productivity tool – it is a liability.
Our Land motion depends on buyers trusting Computer with their most sensitive, cross-functional data. That trust starts here.
3. Our approach: Treating permissions as first-class citizens
Our philosophy with AirSync is simple: permissions are not metadata – they are part of the data itself.
When AirSync connects to an external system, it doesn’t just pull records. It automatically imports the associated permissions, users, and groups, and keeps them in near-real-time sync. The source system – Jira, Google Drive, or any other tool — is always treated as the single source of truth. If a user’s access changes there, that change is reflected in Computer near-instantaneously.
Our architecture handles the diverse ways different systems manage access:
- Object-type-level permissions. Coarse-grained controls like Jira’s “Browse Projects” permission, which can apply to an entire container of objects or to specific items within it.
- Per-item permissions. Fine-grained controls like sharing a single Google Doc with a specific user, where access is unique to that individual item.
This ensures that the access model in Computer is a perfect mirror of your source systems – eliminating drift and manual overhead. That’s what makes Computer safe to land with.
4. Under the hood: The architecture of a universal permissions translator
4.1. The problem: A world of incompatible models
Every external system has its own proprietary way of modelling permissions. A “Browse Projects” permission in Jira – which applies to all issues within a project – is conceptually miles apart from a “Viewer” permission on a specific Google Doc. A scalable solution cannot involve hard-coded logic for every system. That creates a brittle, unmaintainable mess. We needed an abstraction: a universal language for permissions that any connector could speak.
4.2. Our solution: The Authorization Policy meta-object
Our answer is the Authorization Policy – an abstraction layer that acts as a universal translator for permissions. This developer-friendly meta-object provides a clean input for our internal DevRev Loader, the engine that translates a simple policy into DevRev’s native role sets.
This shields connector developers from the complexity of our internal permissioning system. Instead of needing to understand that deep structure, a developer building a new connector simply describes the external system’s permissions in a standardised format: the privileges (create, read, update, delete), the principals they apply to (users and groups), and the targets (the objects they govern).
The strategic case for this design was clear. We considered asking connector developers to interact directly with our internal permission objects — and rejected it. The short-term convenience would have been dwarfed by the long-term cost of tight coupling and brittle integrations. By creating a clean interface, we radically simplified building new connectors, making the AirSync ecosystem extensible and allowing us to add support for new systems far more rapidly. Every new connector is another reason to Land.
4.3. The sync and update lifecycle
Once a connector provides an Authorization Policy, DevRev Loader translates that abstract policy into concrete native Role Sets — automatically, behind the scenes.
To prevent permission drift, we use a snapshot methodology. When the connector detects a difference, it provides a complete snapshot of the current permission state in the external system. DevRev Loader then performs a two-step process:
- It creates a new set of role sets based on the fresh snapshot.
- It deletes all old permissions associated with the previous sync.
A simplified diagram of the Authorization Policy ETL process.
To prevent permission drift, we employ a snapshot methodology. When the connector detects a difference, it always provides a complete snapshot of the current permission state in the external system. DevRev Loader then performs a crucial two-step process:
- It creates a new set of role sets based on the fresh snapshot.
- It deletes all the old permissions associated with the previous sync.
This “create-then-delete” approach, while seemingly blunt, is strategically superior for security and compliance. Creating the new state first ensures there is no momentary lapse in access for legitimate users. And it guarantees that access revoked in the source system is always revoked in Computer – no stale permissions, no drift, no security holes.
5. AirSync in action: Access management across Jira and DevRev
Theory is great, but the real test is how it performs in the real world. Let’s walk through a common scenario demonstrated in our DevRev Live session.
5.1. Scenario 1: Revoking access in Jira
Imagine a user has access to a sensitive Jira project, and those issues are synced into DevRev. They can view the work, see priorities, see assigned users and participate in discussions.
Issues from the Jira project are visible on a Kanban board within DevRev, reflecting the user’s initial access.
Now, an administrator goes into Jira’s permission scheme and removes that user from the group that has “Browse Projects” permission.
A side-by-side view of the Jira permission scheme, showing the user’s name present in the “Browse Projects” permission before the change, and absent after.
AirSync’s periodic sync detects the change. Without any manual intervention in DevRev, the user’s access is revoked near-instantaneously. When they refresh their view, the issues they could see just moments before are gone, replaced with an “Access Denied” message. The sync is automatic and perfectly mirrors the ground truth in Jira.
The user’s view in DevRev after the permission change, where the list of issues is now empty or displays an “Access Denied” message, confirming access has been revoked.
5.2. A step further: Granting additive permissions in DevRev
True collaboration often requires bringing in stakeholders who don’t exist in the source system. This is where AirSync’s layered model becomes a key part of the Land pitch.
Our model creates two distinct permission layers: a foundational layer that is an immutable mirror of the source system, and an optional additive layer managed directly within Computer.
Say you want a product leader or a salesperson to have visibility into Jira issues – but you don’t want to give them a Jira licence or alter the project’s core permissions. With AirSync, you add that user directly to the corresponding synced group within Computer. This grants them access inside Computer, but critically, does not grant them access in Jira itself. The integrity of the source system is preserved. Cross-team collaboration is unlocked.
This is the expanded motion embedded in the product. Land with a team, then safely bring in adjacent stakeholders – without touching the source system.
6. The payoff: Secure foundations for enterprise search and AI
All this architectural rigour – the abstraction layers, the snapshot syncs, the two-step create-and-delete – serves one goal: making Computer not just powerful, but enterprise-safe.
With a perfectly mirrored and trustworthy permission model, Computer can operate across an organisation’s full data estate without creating security holes. When a buyer connects their tools, they can be confident that every employee searching for information will only see what they are authorised to see – governed by the same permissions that control the source system.
An engineer and a finance team member running the same query will get completely different, and equally secure, results. That’s not a limitation – it’s the feature.
This turns enterprise search from a potential security liability into a massive, secure productivity multiplier. And it’s a better answer to the security objection than anything we’ve seen from competitors.
7. What’s next: Towards even deeper granularity
We’re not done. Our roadmap addresses the gaps that enterprise customers – particularly in regulated, security-conscious environments – are asking for today:
- Field-level permissions. The ability to sync permissions for specific fields within an object, not just the entire object. This enables scenarios where only certain users can see or edit sensitive fields, like cost estimates or customer PII.
- Complex conditional permissions (“caveats”). Support for advanced, rule-based permissions – for example, granting access to an issue only when a specific field has a certain value (e.g., when status is “Approved”).
The Authorization Policy meta-object was designed from the start to be extensible, making this a natural evolution rather than a rewrite. These aren’t features on a distant roadmap – they are the capabilities that unlock Computer in the accounts where the biggest Land opportunities live.
To follow our progress and join the conversation, check out the DevRev Discord server or subscribe to the DevRev Live YouTube channel for more deep dives.
