Why Authorization Is Still Unsolved

Jad: Welcome to Trust at Speed, a show about the people building, securing, and governing the future of tech. I'm your host, Jad Boutros. In this series, we sit down with leading experts across privacy, security, and AI to unpack hard-earned lessons and explore how they're navigating an ever-changing landscape.

Today we're joined by Maya Kaczorowski. Maya's career reads like a blueprint for modern security infrastructure: from launching Cloud KMS and co-authoring BeyondProd at Google Cloud, to leading Dependabot at GitHub, to joining Tailscale as its first PM and scaling the organization to CPO. Today, Maya is the co-founder and CEO of Oblique, where she's building self-service access controls. Maya, welcome to the show.

Maya: Thank you so much for having me, Jad. It's fun to hear all that and realize how long we've known each other.

Jad: It's actually been almost twelve years. No joke. I love it. Fantastic. I want to start a little bit with your background, Maya. You studied mathematics during your master's at LSE, and then you started your career at McKinsey, presumably on consulting and strategy, but then you pivoted into working directly on foundational security products in the cloud. What made you make this shift into security and building products, and what was the process like?

Maya: I've always really been into puzzles. When I studied math, I really liked studying cryptography and algebraic number theory. That was a passion and interest of mine. When I joined McKinsey, I did general consulting, but I ended up doing a lot of tech consulting. This was around 2011, 2012, when they were just starting to work in cybersecurity, so I got to work on a lot of early cybersecurity projects: building new cybersecurity programs, strategy for security products, M&A for security products, all that kind of stuff.

So that was a natural jump for me into a product role at Google and GCP. When I joined Google, I joined to work on encryption in GCP. That was an insane role for me, because it was something I was super passionate about. And I'm not a cryptographer, so getting to work on some of this stuff without having a PhD in mathematics was really cool.

Jad: Fantastic. Maya, as part of founding Oblique, you spent a lot of time interviewing small enterprises to better understand their most pressing security needs. I'm sure you learned a number of things that helped you pave the direction for the company. What's your recommendation for a first security hire in an enterprise? What should they be focusing on, and what problems would they tend to see?

Maya: The first security hire of a company, especially somewhere like a startup or an SMB, ends up doing a lot of different things. One of the things people forget is that they usually also own IT. So the first security hire is also the person who has to figure out device enrollment and getting devices to people, and has to figure out single sign-on and 2FA. I was just talking to a friend of mine who started a new first security role last week, and he has to figure out physical access to their office. That's also part of the role.

People think it's going to be cloud infrastructure and whatnot. And it is, but that's the stuff the industry has spent a lot of time on, with dev tooling, DevX, and DevSecOps over the last decade or so. So some of the stuff there is actually way better set up than people realize. Most people have something like Dependabot running to update things. Most people have some kind of security scanning. Most people are using Terraform to set up their infrastructure. But they don't necessarily know what to do for their physical office door. So the role ends up being a lot more of a mismatch than people realize.

Jad: That's fantastic. By the way, in a previous job, I was offered to be responsible for physical security, and I said, absolutely not. It terrifies me. Access to offices is one thing, but when you start to think about the actual security of people in the office, that takes it to a completely different level.

Maya: That's actually one of the things I did as a founder for my team: I bought us all global travel insurance. I was like, you know what, I don't want to figure out how to get you home from a conference. I do not want that to be my problem.

Jad: Wow, that's smart. I didn't even know such a thing existed. So your advice is to focus on identity, single sign-on, 2FA, and things of that nature first?

Maya: My advice is to focus on things that are generally in corp. Actually, the first thing you should really do is build credibility with the team you're working with. Build credibility with engineering, build credibility with leadership, et cetera. Ask questions and figure out what's actually going on. That's the most important thing you can do. We're talking about trust, and if you lose trust, you can't do anything else. So you need to build that trust up with your organization.

Tactically, then, it's making sure you understand any expectations for what you need to get done in that job, and figuring out what the scope of the environment is. Is physical security in scope? Is cloud security in scope? What cloud are you using? All of that kind of stuff.

But a lot of the no-regrets moves tend to be in the corporate space, because engineers tend to take care of the no-regrets moves in the production space first. So a lot of the corporate stuff is rolling out SSO, rolling out MFA, and figuring out a story for where you're going to put some logs. You don't even have to look at the logs. I hate saying that, but if you have logs, put them somewhere and worry about them later. They're the kinds of things you'd like to have for the future, like you're saving up for yourself in the future, rather than tackling a large security project immediately.

Jad: Perfect. Very often, I think, when organizations today hire their first security person, there's already a lot of technical debt and very high pressure to achieve something. So I like the part about building trust with the business and also understanding the status quo and what needs immediate work.

Maya: It's like any other project you might work on, or starting any other job. Get a lay of the land before you start making decisions. But there are definitely some things that should happen as a security person, so getting started on those is a no-regrets move.

Jad: Perfect. Maya, I want to switch gears a little bit and talk about SOC 2, because I read that you recently passed your SOC 2 Type 2 audit at Oblique. Congratulations.

Maya: A few months ago now, yeah. Thank you.

Jad: Fantastic. And this isn't your first time driving such an effort. You worked on it at Tailscale too. Give us a sense of the process. Has it changed considerably since the first time you worked on it? And what do you think is still hard versus easy in the whole SOC 2 preparation and audit?

Maya: For folks who've never done a SOC 2 or another similar compliance audit before, it's a lot of paperwork and evidence gathering, and some amount of actually implementing controls. But we all know compliance is not security. So if you have a decent benchmark or minimum level for security, privacy, and other things, you probably already do a lot of what's required for a given compliance framework.

The hard part I remember from Tailscale was a lot of the process stuff: okay, what is the policy we need for all of these things? Now at Oblique, that's some of the stuff I knew how to do, so it got out of the way very quickly. The things that ended up taking me longer were fairly human-intensive tasks, and tasks that needed new processes. We were a very small company, so we needed to put in place our plan for how we're going to do performance reviews and set up a tool for that. That's one example. Or we needed to do vendor security reviews for our vendors.

I think the big thing that's changed from a few years ago, when I worked on the first SOC 2 at Tailscale, until now with Oblique's first SOC 2, is that a lot of the tooling and automation is great around getting evidence out of systems. So checking that you have the right branch protection rules in GitHub, or checking that you have logs enabled for something, or whatever it happens to be.

Those work really well for things that are systems and not humans, and systems where you have an API. It's easy to connect to GCP or AWS and read what's going on there. You might not have a connection for your meeting recording tool. You might not have a connection for your coworking space booking tool, or whatever it happens to be. That's some of the long tail of what a human ends up having to go look at.

So a little bit like what we just talked about for the first security hire, what's available in the production security space has really improved. What's available in the corporate security space hasn't necessarily significantly changed in the last couple of years.

Jad: That's great. Let me ask you this. A few years ago, I naively thought that cloud providers, and providers of large analytics and important data storage solutions on the internet, would offer their own compliance abilities to their customers, so you wouldn't have to go through a Vanta or Secureframe. You'd just get all of that directly from them. That hasn't happened, and I'm sure it's probably because they don't want to get into the business of auditing. But you found it easy to identify and remediate cloud and other prod issues from your own compliance platform?

Maya: I think it depends on what your stack is. When I was at Tailscale, we didn't use one of the platforms. Part of that was that Tailscale was running in so many different points of presence globally to have DERP servers, so we were using all these smaller cloud providers that didn't have integrations with these tools.

Now at Oblique, our tech is shockingly boring on purpose. So it actually works very, very well, because if you stick to the tried-and-true path, like we're using GCP, Cloudflare, GitHub, and a few other things, they have integrations for all of those. It works. But once you have something a little more unusual, or even a different industry, like if you weren't a software company and you were building hardware, good luck trying to figure out how to approve all the things you need for that.

Jad: Tell me if your journey is similar to mine or very different. I found that if you're using a compliance platform, and there are quite a few on the market now, they're very good at telling you which controls might have some deficiencies, things you need to address, software you need to update. Those are great insights, easily made accessible, and you know what you need to do. You feel all of that work is improving security anyway. It keeps you in check and makes sure you're doing all the things you should be doing.

But then there's the other part, which is evidence collection. I didn't really see that improve over the past number of years, which is why I'm interested in your perspective. I find that the audit itself is still overwhelmingly manual. You have to show proof, like the performance reviews you mentioned. You have to take extracts, redact them, and show them to demonstrate that you've done the right performance reviews, and things like that. And there are hundreds of them. Is that also your experience, or did you see it become much easier?

Maya: I think some of it became easier. Some of the production stuff, in our case around GCP, Cloudflare, and GitHub, has automated tests, and we don't really get questions about that. But for the example you gave around performance reviews, we upload a piece of evidence into Drata, which is what we use, and the auditor still asks for it separately. So I would say that hasn't really changed.

And I'm not the only one with that experience. I talked to someone else about the platform they're using, and they said, yeah, we still just have a folder with all of the evidence, because the auditor doesn't go and look at it in the platform. That was very interesting to hear, that that's the struggle there.

Some of what we build now at Oblique is around user access reviews, and I think some of those lessons come out of that. Like, you want a PDF? We can give you a PDF. We understand that you're going to be uploading this somewhere. A link might have more information, but here's your PDF.

Jad: Fantastic. That's clever. That's really cool. It's possible that auditors are working with so many different platforms now that it's just not possible for them to understand the power of each one of them.

Maya: Or how to use each one differently. I think that's definitely true. It's also a space that, from my point of view, I never really understood. Why are you selling me, as a customer, an audit platform? You should be selling the platform to the auditor. Then the auditor would sell me an audit that's easier because they have a platform. It's a bit of a weird economic situation.

Jad: Yeah. We saw this whole SOC 2 drama unfold this year, with a lot of weirdness. So I'm glad you're not using one of those providers. We're using Secureframe.

Maya: There you go.

Jad: Great, Maya. Another topic I wanted to get your thoughts on, because you've written a lot about it, is authentication and authorization. You've argued that authentication is mostly a solved problem, unless there are really exceptional needs, but authorization is still a critical topic with a lot of considerations we have to be contemplating. Walk us through it a little bit. What are the problems with authorization today? What are you seeing? And what do you think organizations, especially smaller ones, need to do to stay on top of them?

Maya: You mentioned earlier that when I decided to start a company, I interviewed a lot of CISOs and security leaders about their issues. This issue around authorization across their environment was basically the number one issue, which is why this is what I'm working on now.

The issue around authorization for humans is that what you have in your identity provider is a view. Suppose you have an identity provider. Let's start there. We've moved from emails and passwords to having identity providers and SSO. But what you have in your identity provider, assuming it still covers enough of your stack, doesn't actually tell you what somebody can do inside an application. Just because they use SSO to connect to Notion doesn't necessarily tell you what they can do in Notion.

SCIM is the way for you to push specific group memberships or roles to different applications, but it's really inconsistently implemented across the industry. So seeing what a user actually has in an application is very difficult, and it requires going to every single application. You definitely have tiers of problems here: discovering what's in your environment, getting it onto SSO, and knowing what people actually have in those applications. That last problem is the authorization problem I think a lot of people are hitting across the industry now.

Another set of problems that's emerging, or rather becoming more apparent, is around agent authorization. Because we don't have a good view of what humans can do in these applications, when a human starts using their agent to do things, we have a really poor view of what that agent can do in those applications, since we don't know what the human can do to begin with.

I think there's already some work happening here around new standards to have more fine-grained delegated access. OAuth is usually how you give delegated access on your behalf in an application, and we now have this concept of OAuth that the industry is working on that lets you have much more tightly scoped, context-based authorization. But I would say the problem being solved is not new. It's just become so much worse in the last couple of years, if that makes any sense.

Jad: Right. And obviously, with the sprawl of more SaaS applications, on one hand it's great that they connect with identity providers. It removes a whole layer of problems. But on the other hand, there are more of them. We are one, you are one. So there are more things and considerations to manage, with different roles on each.

Maya: That's exactly it. We are six people at Oblique, and we have more than fifty apps that we use internally. That is just a truly absurd number when you realize what it is. How do you figure out what those apps are? How do you track who the users are? How do you do vendor security reviews for all those apps? The SaaS explosion, I think it's called, has really gotten insane. The number of apps the average company has is insane.

Jad: Out of curiosity, how does Oblique help solve this problem? This is the problem you're tackling, right?

Maya: That's exactly the problem we're tackling. Not so much the agent part, but the human part, because that's the problem everyone has right now. We're focusing on figuring out what access people actually have in those applications, down to the role level, giving you context on how they have that access, like when it was granted and by whom, and letting you manage that access in a central place.

That sounds a lot like an identity provider, and the way I like to frame it is that we do everything except SSO. You have SSO set up, it's working, you're using Google or whatever you're using, and it's very reliable. And we're happy to tell you how to give users access to things in individual applications after they sign in.

Jad: Fantastic. So is the goal to stop the need for going to those identity providers and provisioning people to groups and applications? You do that part?

Maya: Exactly. We do the user management, the account management, and the group management, and then push that into applications directly rather than having to go through your identity provider, although we can also do it through the identity provider.

Jad: That's super exciting. You brought up the AI part, so let's talk a little bit about that. There are a lot of voices in security saying that in order to support more agentic deployments at scale, there are some significant problems we need to solve first. The two I keep hearing about all the time are finer-grained permissions and more ephemeral permissions, so that a permission doesn't last too long, only for the time the agent needs to use it. That all makes sense, except these are problems the security industry has been hearing about for easily 12 to 15 years and hasn't been able to solve. You seem to have a different view, that maybe that's not all necessary. So I want to hear how you think about this problem.

Maya: I don't know that I think it's not necessary as much as I think this is an industry-wide change, and it's not something you can wish into existence. Fine-grained authorization is absolutely a gap. We talked earlier about OAuth. So many applications you use today in a business context don't even have the ability to create OAuth clients at all. Or if you have that ability, you have very coarse sets of permissions, like giving somebody read access to everything, or giving somebody the ability to do whatever. If we're trying to give those abilities to agents, they're too wide-reaching, too large for what we typically want for individual tasks.

And usually a human has to go create an OAuth client. You can't necessarily generate them via API, again, for most tools today. You can't do it dynamically, so you couldn't have it done for every individual session. So I think the fine-grainedness and the ability to actually give the correct set of permissions is hard. The solution there is that lots of applications need to implement something that lets them do that. There's no magic solution, unless you put a proxy in front of everyone's agents, which I know some folks are also doing.

On the time-based aspect you talked about, I would reframe slightly. I think the problem is not necessarily time-based, but context-based. It's not that you want to give an agent access for two minutes. It's that you want to give an agent access for the time it takes to complete a specific task. Again, that requires a lot of integrations and connections between tools that we don't necessarily have today, or don't necessarily have a way to represent today.

I do think we should build all of these things. My reflection is more: what can you actually do today? What you can actually do today is start to audit some of the permissions your humans have, and move not necessarily toward least privilege, but toward more correct privileges for those humans. If I, in my role, am able to send money to somebody who sends us an invoice, an agent can do that on my behalf as well. Well, should I even have that permission? Is that the problem? Or is the problem that the agent doesn't have the right controls to stop it from taking that really risky action? So I think there's a bit of delegated consent, plus what the user actually needs access to.

Jad: That's perfect. Maya, I am admittedly a little disappointed that in some cases the permissions are still very, very coarse. I've had this experience in two different ways not too long ago. One was when I was trying to use a new AI-based CRM tool, very new and trendy. The minute I logged in, it immediately asked for full access to my email. And I'm like, okay, surely you understand that as an admin, maybe you don't want to do that. Are there alternatives? There were none. Your choice was this or the highway.

But even with much more established products, like Google Docs, we were building an integration and wanted some permissions that weren't unnecessarily broad but would allow us to do certain things, and that combination didn't exist yet. Even for human needs, before even getting to agentic, why do you think we're a little slower to act in those spaces?

Maya: I think it's just overly complex. If I put my product manager hat on, one thing I've had in many jobs is ownership of the IAM system for the product. And it has come up many times: we should do custom roles. We should let people mix and match any sets of permissions they want. My pushback has generally been, no, let's make the standard set of roles people actually use for normal use cases. Then if people still need custom roles after that, if the product is still sufficiently complex that it needs custom roles, then do it.

I think we have a problem with a lot of the products we use today, where you don't even have that first set of roles. The correct answer would eventually be to do custom roles, but they're hard to explain to users. People don't necessarily understand the full set of permissions. They're not necessarily going to pick the right set of things, and they're going to get stuck in all kinds of ways. But where we are in 2026 with AI, that is increasingly the correct direction to go in. You should probably still push users toward sane, known-good paths, but if people want to do something weird, they should be able to.

You were talking about building an integration with Google Docs. In building a lot of our integrations, we've seen what a world of difference it is when a company and product clearly decided they want people to be able to integrate. They make it very easy to get a test account, very easy to publish an integration, get the right set of scopes, file a feature request, or whatever it happens to be. And then other times we're reading API docs and really basic stuff isn't in there. So you have both ends of the spectrum.

I think more and more, ease of access for your agent or for a human is going to be really important in how successful companies actually are in the market. Can you fully interact with this product via an MCP server? Do you have published API docs an agent can go read? Can somebody self-serve create an OAuth client? These are going to become very baseline capabilities down the line, but right now they're going to make some products significantly more adopted than others.

Jad: That's fantastic, Maya. You also brought up the test account part, and it's something I've personally struggled with quite a lot. Of course, it's a little tougher for smaller enterprises, because you want to integrate with many different providers, and you don't want to pay huge sums of money just to have the right instance for testing. But I've also found that with some, it's very, very hard to even get an instance in the first place. Even when you go through sales, it's not made easy. Have you struggled with that as you're building?

Maya: Yeah, I've struggled so much with this. I think the easy part of building integrations in 2026 is the code. The hard part is getting the test account, getting the partnerships person to talk to you, and all of that. I think that's what's going to slow down a lot of companies that are trying to build a lot of integrations.

Jad: Absolutely. Let me ask you, because you work so much on authorization: once you have all these agents operating with their own identities in a more fine-grained permission context, how hard do you think it's going to be to do these access audits on a regular basis and actually know for a fact that things are working the way you expected? And not that it was misconfigured and you never had any of the security benefits you thought you had. I think that's actually going to be pretty challenging.

Maya: I think that's right. And I think part of that is going to be just the volume. The volume of agents and the volume of requests they send is going to be so ridiculous. When you get a PR now from Claude and it spits out a blob of text, do you read all of it? Do you read its full description of what it's doing? I think we have the exact same problem with an agent requesting 200 permissions to make thousands of API calls. How can you actually parse through that and see what's impactful, valuable, and important? I think the volume is going to be the thing that really drowns out everything else.

Jad: Great, Maya. This was honestly a fantastic conversation. I'm so grateful you made the time to come on our podcast. If people want to hear more and follow you, what do you recommend? Should we post a link to your LinkedIn, or is there some other place you'd recommend?

Maya: I am on LinkedIn, Maya Kaczorowski, and our company is oblique.security.

Jad: Fantastic. Maya, thank you very much. Have a wonderful day.

Maya: Thank you so much, Jad.