Graham Neray, CEO and co-founder of authorization startup Oso, can point to recent examples to make his case that AI is breaking authorization.At Supabase, an LLM agent with broad database privileges was tricked into leaking secrets.ServiceNow issued a fix for a vulnerability in which data could be inferred without authorization.An agent at Replit went rogue on the codebase and deleted the entire production database.“In most companies today, we accept a certain amount of over-permissioning to make it possible for people to do their jobs. … And we can do that because there’s this finite limit on your time or resources as a human to do bad or stupid things,” Neray said.“If you give an agent permission to do the same things that any human could do, there’s no guarantee that it’s going to do what it’s supposed to do. There’s no guarantee that it’s not going to get tricked. … This is kind of what I mean when I say LLMs are really a paradigm shift.”Large language models (LLMs) are fast and tireless, capable of causing damage at superhuman speed.Until the rapid rise of AI, software performed only the actions it was specifically programmed to do. Agentic AI, however, has changed that with agents able to learn, adapt, make decisions and take action autonomously.Well-founded fear is the reason most companies adopting AI are using it for internal support agents that let them search over a knowledge base, rather than on sensitive company data, according to Neray.While Oso doesn’t have all the answers at this point, it is focusing on this new class of security risks.AI Adds to Security RisksBroken access control tops the list on OWASP’s Top 10 web application security risks. And Gartner has predicted that at least 30% of generative GenAI projects will be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls and because companies are struggling to realize value from them.“No one’s shipping AI workloads that touch sensitive data because they don’t feel like they have a handle on security, and they don’t want to be on the front page of the Wall Street Journal,” Neray said.He cited three problems:1. LLMs are not trustworthy.“LLMs interpret natural language, which means they can misunderstand things. They can be tricked to do things. They can do things by accident. And you can’t let a being that is probabilistic and not deterministic … determine who’s has access to what. It can’t be like, you know, ‘Hopefully the LLM gets it right,’” he said. Solving this is something he says the industry has yet to figure out, he says, so it’s essential to put access control somewhere outside of them.2. LLMs need a lot of permissions to be useful“I may need to give an LLM a lot of permissions in order to do its job, but I really only want to give it permissions at any one point for any one task. [These] are much, much more scoped down in order to limit the bad things it could potentially do. And this is a different model,” he said.A Venn diagram illustrates that a user might have a certain set of permissions and an LLM a specific set. But the required permissions for a certain task might be only a much smaller subset. This would require at runtime radically narrowing down the permissions for that task.“This is basically like dynamically changing something’s permissions, which is just not a thing that anyone is doing today,” Neray said.3. The data the LLM needs is stored in a completely separate place.You might have a vector stored in a database, but permissions are stored in your application database. There has to be a way to bridge that gap.Oso was built for defining your authorization logic explicitly in your application. It integrates directly into the data layer, having recently added an integration with SQLAlchemy that automatically figures out your local authorization configuration with LLMs. SQLAlchemy is an open source Python library that provides an SQL toolkit and an object–relational mapper (ORM) to provide flexibility for developers working with databases. It enables you to filter database queries based on your application’s authorization logic, which is enforced by converting it to SQL filters.Available so far only for Postgres, it is exploring integrations with MongoDB and Elasticsearch as well as ORMs like Prisma and Django.The Need for Fine-Grained PermissionsIn a previous article, Neray explained how you can use a vector database and retrieval-augmented generation (RAG) to enforce permissions in LLMs. Yet he maintains that the most commonly used security tools — OAuth and Model Context Protocol (MCP) — remain inadequate to lock down LLM permissions to the task level.He considers OAuth permissions too coarse-grained to be useful for scoping authorization to a task.“OAuth providers are out there going around talking about fine-grained permissions in OAuth, and what they mean is taking all those actions and slicing them up into things that are very concrete: read email, delete email, draft email, you know, discard draft of email, so on and so forth.That’s the level at which OAuth can help you enforce permissions.“However, if you wanted to say, ‘Read Only these emails or delete only those emails or have access to these emails for just one day,’ you can’t do that sort of thing in OAuth. … What you really need for this agentic world is fine-grained authorization down to the file level, the resource level, the object level, that sort of thing. And MCP is just using OAuth.”Oso developer advocate Greg Sarjeant explains in the blog post “Why LLM Authorization is Hard” that specifying to the LLM which emails a user can delete requires resource-level authorization, which is not feasible with OAuth. It can only determine whether the user can delete emails at all.And he says of MCP:“The MCP Server is just a bridge between agents and tools. It doesn’t know anything about the inner workings of the tools. It doesn’t know how access to them is governed, or what data they expose, or how to determine who should have access to that data.”Automating Least PrivilegeOso advocates the idea of automated least privilege. Impersonation — confining the LLM’s permissions to that user’s permissions — is one way to scope down access, though there still might not be a clear mapping of the permissions required for a given task.“Today, Oso gives you the building blocks to make that yourself, and in the future, Oso will give you a much more turnkey solution to just that problem, but fundamentally, our architecture is very well suited to solving this kind of a problem,” Neray said.He said the company is focused on being “AI native,” which he describes as being able to slot well into new developer workflows.An example would be developers using Cursor wanting to be able to ask questions about their Oso implementation from Cursor. There’s a way that we can enable that, by building an MCP server for Oso. We have internal POCs of this. We just haven’t released them yet. … It’s this kind of work.”In support of this, it recently released a guide to building a permissions-aware RAG chatbot as well as a technical guide to AI authorization.The post Oso Focuses on Fine-Grained Authorization To Thwart AI Risks appeared first on The New Stack.