Your AI agent needs the same auth as a person
AI agents need the same auth as the people they act for. Authentication, authorization and boundaries work the same whether a person clicks in a portal or an agent calls a tool. Learn to map who may approve what, check roles with RBAC or ABAC before an approval, and borrow escalation from ticket triage.
What you will learn: - Map who may approve what in a system with many parties - Treat an AI agent like a human employee - Reuse the authentication, authorization and boundaries you already run - Check the role with RBAC or ABAC before any approval
#aiagents #authorization #rbac
Chapters
- Map who may approve what
- Handle many parties in one system
- Treat an AI agent like an employee
- Reuse auth, authorization and boundaries
- Borrow escalation from ticket triage
- Check the role before approval
Transcript
Map who may approve what
So this is the crew, the three crew of team members, which is actually doing like the trip planner will do the planner and booker will do booker job and messenger will send the message, and then all will call the travel system and it will say like whether the permission is there or not. For example, if Priya logs in to the board, and if she tries to approve it, it won't allow and it won't approve. Only Dana, the manager need to approve it. So you need to control you know the permissions, what permissions those users have, authentication and authorization. This is very important when you are actually building your agentic system. Like there can be multiple multiple parties which is involved in an agentic system.
Handle many parties in one system
for example, in an immigration products, there are multiple users which will be involved. Same as any any any platform where immigration domain is almost like legal domain where the complexity is more around it's not like customer success board where it can hallucinate with certain answers and then redirect to or deflate to customer support person. Here you need to verify whether the answers are 100% right, unless and until it is 100% right, you can't say that you can always go back to your you know the human to do the rest of the work. So here the main challenge what we face at Jabadical where I'm consulting, the main challenge will be it is a multi-party system, like the user who is actually coming from point A to point B, they will be uploading their documents and so on, and the user who are actually immigration lawyers, they are they are providing the consultancy for those people on what need to be done at what time frame and so on, and then the people who are actually sponsoring that immigration, though those are the HR people, though though they will be monitoring whether anything is escalated or in wrong direction, because they are the one who is anticipating this person join their team at right time, or their family joins with him at right time, so they are the one who is coordinating. So, all these people are actually coordinating within an immigration system, and here if you are not defining your authentication and authorization very well with necessary permission. How you are building your permission layer within that agentic system, then it can easily go right. So that is where the complexity of building an agentic system in production compared to you know a demo environment is much easier. So for for this example, again, like it's still a demo. so what I am doing is more like I'm simulating a couple of users with their roles and so on, but it is not the same in a production environment where you are actually building what kind of permissions and what kind of boundary which is which is there for each users, and that is where the complexity will come into picture, and the board says done.
Treat an AI agent like an employee
Most of the things are usual system design, right? Like authentication or authorization, whether an AI agent is doing on behalf of us, or as a human, we are going into a portal and we are doing it. Authentication and authorization will work the same. So you are basically cloning some parts of like when you are creating an AI employee, it is the same as a human employee as well. Only thing is you are basically delegating what are all the processes which can be automated by that AI employee.
Reuse auth, authorization and boundaries
So these are the same, whether you do it or a agent do it, the permissions what you are providing that is system that system won't change regardless of whether you are building an agentic system or you are building something as a human portals. So, authentication, authorization, and boundaries. For example, the same way when you are defining your boundaries, how many times an user can do this is not new to agentic system, right?
Borrow escalation from ticket triage
So before as well, ticket triaging is a process even before AI we used to do. Like the first time we will we will try like okay, whether it is whether it is an issue which will be directed to the customer. First, it will come to the customer support, and from the customer support, they will see okay. This is a revenue problem, so I will redirect to revenue department. This is an engineering problem, so I will give this feedback to the engineering department, and the customer support person will act as the act as the you know center of contact, and they will be sharing the information. Hey, we already redirected that issue with higher priority to our product and engineering team, and you can take care of it. Now, if you are taking out this customer support person and you are building an AI agent, the rules are going to be the same. How it is going to root and that logic, what rules you are building, what boundary you are building. So sometimes, as a human, you will also have a decision paralysis, like whether this needs to be given a high priority or low priority. Then you will consult with the respective VP of product, and hey, hey, this kind of request is coming in, and there are multiple such requests. What I need to do, and you will then the product person based on their backlog will define what is higher priority. The same thing can happen for a for an issue as well, like incidents. like sometimes the customer will come and say some incident is going on. I am not able to log in to the portal, and there are flurry of messages which is happening, then the customer support manager is not the one who is deciding what to do, they will escalate to the management, and management will decide okay, this is a serious incident which is going on for multiple users, then we need to have a general communication channel that platform is down or platform has this vulnerability, so we are taking down and we are fixing that and so on. So the same applies for AI agent, whatever work you are replacing at the end of the day, you need to think what boundary it has, when to decide and when not to decide. So that is where now even decision-based models are getting popular, like JEV. they they do more fast decisions and more accurate and fast decisions and more cheaper in price. So you can integrate multi-model systems like when to call LLM, when to call JEV, and so on. So that's the same approach which has been applied here.
Check the role before approval
And then the approval process, like you need to check whether this person, like this is very dummy example where we are checking whether it is a manager, and if it is a manager, then we approve. but in a real case scenario, we need to implement RBAC or ABAC, like like rule roles-based access control or attribute-based access control. then automatically we will be able to define okay, these are the roles, and for that role, these are the permissions, or these are the you know process, and for that process, these are the permissions. So we can define that and we can able to properly acknowledge what is allowed and what is not allowed.
This lesson comes with Pro, $149 a year: Get Pro. This lesson is cut from the free Lightning session Build a Multi-Agent System with MCP. The Live Labs build the same system with you, free, on Thursdays: see the Live Labs.