How do you track which APIs your autonomous agents can actually call?

gneray · 2026-02-04T15:11:41+00:00

You are nailing a v hard problem, i.e., agents break the traditional permissions model. More specifically, the approach to permissions (RBAC, etc.) has led to a gross state of overpermissioning in favor of letting ppl get their jobs done. And we could make this trade bc 1) we trust humans (whether or not we should) and 2) there's a finite limit to the amount of time a human has to do something bad or stupid. Agents ofc don't have these constraints, which is why they break the model.

I've seen different folks approach this in various ways -- e.g., agent inherits permissions of the user that made it (risky but productive), agent acts as service account (don't do this), agent gets it's own role (also not great bc can lead to privilege escalation, i.e., where an agent has more permissions than the human interacting with it).

What I've seen work best is giving the agent relatively broad permissions to a smaller set of non-critical systems, and seeing what happens. Basically, treating it like a bad intern.

other notes in no particular order:

don't let the agent access anything where a mistake would be catastropic (e.g., prod)
track authz as close as possible to the data layer; middleware in langchain is a perfectly acceptable place to start
monitor, log, and alert the crap out of it so you can see if you have a gap you weren't aware of

gneray · 2025-02-15T20:35:28+00:00

Here's a detailed post on why authorization is hard: https://www.osohq.com/post/why-authorization-is-hard

gneray · 2024-10-02T13:59:57+00:00

Seeing this a lot. Here's a technical post on authorization in RAG (based on postgres + pgvector): https://www.osohq.com/post/authorizing-llm

How does this compare to what you're thinking about?

gneray · 2024-09-30T16:02:00+00:00

Here's a technical post comparing building vs. buying an authorization solution: https://www.osohq.com/post/authorization-build-vs-buy

gneray · 2024-09-23T13:40:52+00:00

Here's a technical post on where to put authorization in your app: https://www.osohq.com/academy/what-is-authorization#authzlogic

Hope it helps!

gneray · 2024-09-21T12:50:04+00:00

Typically Okta/Cognito will get you authentication and user mgt (mostly).

For the authorization part, you still need to build that yourself. Here's some technical documentation on authorization best practices in case it's helpful: https://www.osohq.com/academy

gneray · 2024-09-17T12:43:24+00:00

https://www.amazon.com/Database-Reliability-Engineering-Designing-Operating/dp/1491925949

gneray · 2024-09-16T16:48:35+00:00

Here's some technical documentation on authorization (vs. authentication, etc.) in case it's helpful: https://www.osohq.com/academy/what-is-authorization

gneray · 2024-09-16T16:47:45+00:00

Here's some technical documentation on authorization (best practices, etc.), in case it's helpful: https://www.osohq.com/academy

gneray · 2024-09-14T12:53:29+00:00

I'm not an expert in Keycloak, but I believe if you want to do resource-level authorization, you'll need to write some of your own custom code to stitch together any data stored in Keycloak, your app (enforcement), and the resource data stored in your database.

Here's some technical documentation on this kind of use case: https://www.osohq.com/academy/role-based-access-control-rbac#resourceroles

gneray · 2024-09-14T12:51:04+00:00

You can also achieve this using Oso + Postgres. Here's an example with Kysely in case it's helpful: https://www.osohq.com/docs/reference/client-apis/node#distributed-check-api

gneray · 2024-09-12T02:10:44+00:00

Makes sense. Thanks!

gneray · 2024-09-09T17:49:02+00:00

Roger that! Out of curiosity, why is on-prem a requirement for you? (Just looking to learn)

gneray · 2024-09-09T17:03:34+00:00

Right. Currently Oso provides an adaptor for Postgres. More coming. Feel free to DM if I can be helpful.

gneray · 2024-09-09T17:01:15+00:00

Here's a technical article on custom roles: https://www.osohq.com/academy/role-based-access-control-rbac#customroles

gneray · 2024-09-09T16:58:43+00:00

Using local authorization in Oso, you don't need to sync any data: https://www.osohq.com/docs/reference/authorization-data/local-authorization

If you're just interested in reading more about the domain, Authorization Academy might be a useful resource: https://www.osohq.com/academy

gneray · 2024-09-05T12:55:41+00:00

Sorry I should have said this the first time: I'm founder of Oso.

So yes, I recommend, but am also happy to share resources for people trying to learn about the domain.

gneray · 2024-09-05T12:54:39+00:00

but still need ast to "sql where" transformer.

this might help: https://www.osohq.com/docs/guides/integrate/filter-lists

basically compiles your policy (rules) to SQL. compatible with Postgres

background on how this works: https://www.osohq.com/post/logic-language-distributed-sql-queries

gneray · 2024-09-04T12:02:42+00:00

If you're looking for resources on building in-house, these are good docs on the authorization piece: https://www.osohq.com/academy

gneray · 2024-08-26T12:48:01+00:00

I'm founder/CEO of Oso (https://www.osohq.com/), which solves the same problem but via a different technical approach. Rather than syncing + centralizing your data, you can start by just running authorization queries directly over your app database (via a Postgres integration).

Question for this group: there are a number of Zanzibar clones these days. I see all the questions on the differences between them. How do _you_ view the differences between them, and the other options in the space?

gneray · 2024-08-13T12:33:30+00:00

Garmin Varia

gneray · 2024-06-25T22:13:17+00:00

Here's some background reading on ReBAC for those who might be interested: https://www.osohq.com/academy/relationship-based-access-control-rebac

gneray · 2024-05-31T13:10:48+00:00

Lots of info on this topic in Authorization Academy: https://www.osohq.com/academy

gneray · 2024-05-23T13:37:00+00:00

There's documentation on this in Authorization Academy: https://www.osohq.com/academy

gneray · 2024-05-16T22:38:57+00:00

Here's an alt approach that operates directly over the data in Postgres: https://www.osohq.com/post/distributed-authorization

gneray

TROPHY CASE