If you’re like many teams, you have an enormous backlog of agentic AI projects, but feel blocked by approvals. Approvals for tools. Approvals for use cases. Approvals for more approvals. The primary reason is a lack of trust in these new systems where it seems that every day is filled with news of overly-ambitious agents dropping production databases or products with critical vulnerabilities.

The missing piece? Authentication and authorization.

Are users who they say they are?

The simplest solution here is to use your organization’s SSO. This ensures that the users interacting with your agents are properly authenticated. And while it might be unpopular, access from personal devices needs to be locked down. Whether that means only allowing access via company-issued devices or installing mobile device management (MDM) software, your IT team is more likely to approve your agent if it can be 100% sure that the user on the other end of Slack is who they say they are.

Permissions and who should manage them?

When it comes to what system to use, the answer is “it depends”. You probably won’t pick just one approach for your agents. Whichever method you choose, handle permissions outside of the agent itself. While there have been many improvements in guardrails, LLMs are still very vulnerable to prompt injection attacks, where users can trick the agent into doing something that it should not. The part of your workflow that handles permissions should be hard-coded to grab the user’s ID from the above authentication and pass that directly to your permission service without the agent generating this call.

Delegated permissions

Delegated permissions are ideal when your agent is connecting to an existing system that manages its own user access. For example, if your agent is letting users submit and approve time-off requests in ADP, the best thing to do is to have the agent act on behalf of the user.

Application-enforced permissions

Many times, you won’t have an existing system to hook into, or that system doesn’t match with the access that you want your users to have. In these cases, your application will need a way to have policy-based access control (PBAC). One such library to do this is CASL, which allows for fine-grained authorization. For example, if you are building an AI-powered HRIS agent and want to limit who can see sensitive employee data, application-enforced permissions let you define exactly that. If your agent touches PII, or you need to control access at a level the source system can’t, this is where you need to be.

How to get your agent approved

Remember, your organization’s IT and cybersecurity teams are working with you to ensure a safe deployment. IT isn’t your enemy here. They’re trying to avoid being the team that approved the agent that made the news. In order to help them help you, handle permissions on a use-case by use-case basis instead of all at once. Create project design documentation that explicitly defines what scopes will be included, and scope it tight. The teams that get approved fastest aren’t the ones with the best demos. They’re the ones who made IT’s job easy.