Authorization Built for Developers: Our Investment in Abbey Labs
By Noah Carr and Johanan “Joj” Ottensooser
Abbey Labs was built to solve the authorization problem by taking a developer centric approach to the problem: authorization as code. We’ve felt the problem personally. We’ve seen the success of developer centric security and “as code” solutions. We’re proud to lead their Seed investment round.
The Authorization Problem
Managing who is permitted to do what actions with your data and your infrastructure is some of the most important work in securing your software and organization. This work typically comes in two parts: authentication and authorization.
You may be more familiar with authentication. It answers the questions (1) are you allowed “in” and (2) are you the person you say you are. Think usernames, passwords, and two-factor authentication. Authentication lets you in the door.
Authorization (or Permissions Management) can be much more nuanced. It answers the question, “what are you allowed to do once you are in?”. It helps you manage who gets access to what data, and who can read or edit data sources, infrastructure, or code. Based on conversations we’ve had with data teams, we believe that this complexity—this “authorization hell” is a leading cause of stress and data engineering churn in companies. There are too many points of friction, and most modern solutions are not designed with engineering in mind.
One of the authors of this article, Joj, saw this firsthand in his previous role as a data product manager. From his experience, authorization can drive talented engineers to frustration in two ways. First, they are being pressured to approve and expedite authorization requests, but for security and compliance purposes, they need to wait for other stakeholders, so they feel like a cog in an approval machine, but the only cog that’s being shouted at. Second, this is administrative work that’s a bit of a time-vortex, and steals resources away from the work they are most excited about, doing good engineering and delivering new products. It can feel like the worst type of bureaucracy—processes that the team is subject to, responsible for, but not in control of.
Co-Founders Arvil Nagpal and Jeff Chao, too, have firsthand experience with this problem after spending several years at large companies tackling authentication and data infrastructure. Our alignment on the problem space made the Abbey Labs team a team we were interested in supporting.
Abbey Labs’ Solution
Abbey Labs is working to turn the existing, painful paradigm on its head by building a developer centric approach to authorization. Engineers are already familiar with infrastructure as code. Why not loop authorization into the same workflow?
Their approach separates policy from infrastructure from enforcement by building authorization into the code that defines an organization’s cloud infrastructure. What used to fall solely on the Data Engineering and Data Product teams is now distributed.
The engineers now translate a policy into code, which is embedded into the infrastructure as code framework that governs the systems that they are managing permissions for (any infrastructure that can have its permissions managed through terraform).
That’s it. That’s the job (at least for the engineers). All the other steps, the validation of policy and the final approvals, are managed by Abbey Labs’ software and executed by the subject matter experts—the data product owners, compliance teams, or other relevant stakeholders.
We think it’s a win for security if an organization’s legal and compliance policies around permissioning are enforced programmatically rather than by people manually interpreting those policies at the margins. We think it’s a win for the data product owners, the people requesting permissions, and any other stakeholders in the process, who’ll now all have visibility of the request, the remaining steps that are required, and which approvals are holding up the process.
But we are most excited about what Abbey Labs could mean for engineers, who could stop acting as data bureaucrats. Once engineers do the initial work in Abbey Labs, they can step out of the process, and devote their time to working on delivering new things.
Why we think this is important
We believe Abbey Labs has the potential to reshape how the industry thinks about solving authorization challenges and counteract a growing engineering headache that’s approaching untenable. We’ve explored several approaches to these issues over the years, but we didn’t believe there was a viable path to aptly attack the problem until we started working with Arvil and Jeff.
We see a paradigm shift happening in technology, with enterprise solutions becoming more developer centric, with a parallel focus on simplifying workflows and removing underlying complexity.
We see this progression to developer centricity as no different in security. As the number of assets that people need access to grows in conjunction with more fine-grained authorization necessary to maintain security, plus engineering’s demand for simpler and easier-to-use tools, we think people need to start thinking about the problem differently.
Arvil and Jeff have a deep understanding of the evolving cloud-native environment and ecosystem, while also bringing valuable perspectives from both the authentication and data spaces. We worked closely with Arvil and Jeff on the earliest iterations of this product, and have seen their approach develop and resonate with their design partners and broader market.
We are thrilled to be partnering with them on this journey and look forward to sharing more about their progress in the future. Our investment in Abbey Labs is in line with our commitment to strong founders, great products and to those bringing the next generation of enterprise software to market.
Abbey Labs’ Open Beta
Abbey Labs has released their open beta. If you’ve felt authorization hell, or if you’re interested in being a design partner, sign up for the open beta here: https://www.abbey.io/