Low Code Permissions Startup Permit.io Launches Powerful Access Controls

This week we had the pleasure of talking to Or Weis, CEO&Co-Founder at Permit.io. The company builds unprecedented permission tool that allows flexibility and full visibility into maintaining the complex system of enterprise permissions. Before starting his venture at Permit, Or was a founder at Rookout, a company that provides secure and fast data access.

Watch&Listen to the full interview here.

Or Weis

CEO&Co-Founder at Permit.io

Or, can you give a bit about your background for the audience who isn’t familiar with Permit.io?

In 2017, I co-founded and ran a company called Rookout, a production debugging solution and a dev tool company. While in Rookout, I rebuilt our access control five times when the company wasn’t even three years old. There realized I didn’t want to do it once, let alone five times. With my co-founder Asaf Cohen, who worked at Facebook then, we saw Facebook invest a team of thirty people for half a decade to build their level of access control. We knew it was an annoying problem for developers that would only get worse. So that brought us to create Permit, a full-stack permission solution with the basic premise of you, as a developer, not having to build permissions ever again. Because we give you a solution off-the-shelf that you can bake into your software while focusing on building your actual product. 

At Permit, we built our solution on an open-source project called OPA (Open Policy Agent). And created an open-source project called OPAL (Open Policy Administration Layer). There, you’ll find user management with the ability to assign roles, API key management, sequence management, audit logs, invites, approvals, impersonation, emergency access, and a simple-to-use Policy Editor. 

On top of that, we provide end-to-end experiences as part of Permit for Low Code experiences that generate code for you and allow you to manage your entire authorization mission space. The idea is that you can use a simple interface to generate the rules you need, instead of learning complex policy languages, like Reco.

I have interviewed Rookout before, where it seems you are a founder and used to be CEO there. Can you talk about transitioning from a dev tools company to a security company?

I’d say both companies are dev oriented. They’re not pure DevOps or pure security. At the core of both companies are catering to developers’ pain points. I view Permit as a DevSecOpc company. All the stakeholders get value from our product, but we start from the developers themselves as they delegate and can build things for other stakeholders.

On top of that, building critical infrastructure components with Rookout taught me a lot about security. With a debugging solution you embed into your production, the product might gain visibility to sensitive information because it’s essentially all the information within the application. But we found a solution called Controller that integrates with a product without exposing all of its data to ourselves as a third-party service. All the data flows through the Controller instead of the Rookout cloud. 

You can use Permit to enforce permissions in your product without exposing any data to Permit itself.

That was a critical architectural moment, and I’ve leveraged that understanding into building both OPAL and Permit. Permit decouples your data plane in your control plane through the open architecture, which keeps all your decision points and microservices for authorization up to date. It does so by sending instructions on where to get the data, so each of your services gets only the data they need and the policies they need when needed. Therefore, each service can work in a zero trust need-to-know basis architecture without exposing sensitive data to the local server or the Permit cloud and without being dependent on its availability. So because the cloud manages it, but it runs locally, even if Permit is down, even if your service isn’t connected correctly, everything continues to work seamlessly. 

I agree that we are seeing developers play a bigger role in security. So can you give us a deep dive on what exactly Permit is trying to solve for developers?

Yes, with the shift left, it is very apparent. In the past, security was solely tied to the CISO group, security engineers, or analysts trying to build moats around the different components of the products the organization was building. But as things become more interconnected, it becomes impossible to continue doing so. First, the software’s components are shrinking with the introduction of microservices. And if you try and silo all of them, in the best case scenario, you’re going to have a bad time; in the worst case scenario, it will fail, and everything will be vulnerable. Instead, we need to sprinkle access control and security into every component we build. And that means that the responsibility is at the hands of developers. Now, developers are becoming one of the most critical personas working on security. It’s also clear that this trend is only going to accelerate. So we must enable them to work on this before it becomes too challenging to even think about.

I hear you have a patent pending for your newest capability: Attribute Based Access Controls. Can you explain why this is so important?

At Permit, we started with Role-Based Access Control. Then we thought about taking something so complex and simplifying that to the point where teams can work faster and with less frustration. And we ended up with an Attribute-Based Access Control solution. It is so different from any other enabling policy out there that we decided to patent our solution. 

The idea is to recognize that because your software is evolving, the permissions challenge is evolving too. At a small company, everyone starts with a policy model I call “admin/not admin.” As a developer, I’ll be the admin. Everyone else is not an admin. I can change things, and you can’t. But when the product gains traction, people need more permission to manage access to applications and infrastructure. And you move from admin/non-admin model to admin/not admin/super admin one. Then you move to access control lists where you have a specific list of who can do what; those are often hard-coded into the database or the code itself. 

Then you often find yourself at RABAC (Role-Based Access Control), which is the bread and butter of the permission space, primarily because it’s easy to think with RABAC, and most people know it. Usually, companies end up there because they have a customer saying, can you also give me roles in your application? So you almost invariably find yourself in RABAC. But RABAC doesn’t cover all the scenarios since it works by having roles that are assigned to users. This is exactly where our Attribute-Based Access Control solution comes into play.

What do you think about the competition in the market? Is there anything similar to your company or the solution that you are offering now?

The space is just warming up. After the authentication space warmed up ten years ago, no one will say they will not use an authentication solution. No one will start building authentication themselves. It just doesn’t make sense and is too critical for security to be overlooked. 

Now authorization and permissions start evolving in the space. Many customers want to adopt this solution, especially in highly compliant spaces like healthcare and FinTech. Of course, we can see many other players coming into the space, but our perspective is unique. It starts with empathy. We provide ready-made solutions to embed into your back office and your application. Then essentially, with us, you don’t have to write policy code, build a user management interface, or build approval flows unless you want to. That’s what’s unique about Permit – being empathetic towards developers and the other people working at organizations.

Or, thanks so much for sharing and for taking the time. Hope we can have you on the show again sometime soon.

Stay tuned for more great interviews coming your way!