The Architect's Guide to Agentic Runtime Security: Securing AI Agents in Production
Over the last twenty years, I have helped organizations modernize complex platforms, moving from brittle monolithic systems to resilient, event-driven architectures. Today, the focus of enterprise transformation is shifting toward AI-first systems. Engineers are being tasked with building AI for their companies. But there is a real problem. Most engineers are not identity experts.
AI agents are no longer just passive chatbots. They are active participants in your infrastructure. They connect to databases, call external APIs, and interact with SaaS platforms like Salesforce. Governing how these agents access your systems is what we call agentic runtime security.
I recently wrote an article on the OWASP LLM vulnerabilities on Medium where I discussed how prompt injections and data leaks threaten enterprise AI. Today, we need to take that a step further and look at how we secure the runtime environment itself.
The Master Key Problem: Why Static Credentials Fail
Imagine you hire a temporary assistant to organize your office filing cabinet. You would not give them the master key to your house, your car, and your bank vault. You would give them a single key that only opens the filing cabinet, and you would ask them to return it at the end of the day.
Traditionally, software workloads use hardcoded, static credentials. A legacy application might have a permanent API key to a database or a cloud provider. For AI agents, we strongly recommend against this practice. We refer to this domain as non-human identity management.
If an AI agent is authorized to read and write to a PostgreSQL database using a static credential, a successful jailbreak or prompt injection means the attacker can read or write anything in that database. We want to strip away that standing privilege.
Unlike traditional AI models that respond to queries within defined boundaries, agentic AI systems can take actions with real-world consequences including sending emails, executing code, modifying databases, and making API calls. (Vectra AI, Agentic AI Security Explained)
The Shift to Dynamic Credentials
Instead of static keys, we need dynamic credentials. At the exact time of evaluating an action, the AI agent must request access and receive credentials that are strictly bound to that specific session and intent.
Dynamic credentials are just-in-time tokens created for a specific task. They are automatically revoked at the end of the session, whether that session lasts two minutes or two seconds. This approach heavily limits the blast radius if an agent is ever compromised.
Layering in User Context with OAuth 2.0
Most AI agents today operate with a human user in front of them, interacting via HTTP or another web interface. To secure the system, we must understand exactly who that user is and the context of their request.
This is where your Identity Provider steps in. Whether you use Okta, IBM Verify, or another platform, your AI agent needs to work seamlessly with the Identity Provider. This relies on the standard OAuth 2.0 authorization code flow. When you click "Log on with Google", you see a redirect asking if you authorize the application to access your profile or act on your behalf. We must implement this exact standard for AI agents to ensure they are properly tethered to a human identity.
Recommended by LinkedIn
Securing High-Risk Operations with CIBA
Basic OAuth 2.0 handles standard read and write permissions well. But what happens when an AI agent needs to perform highly sensitive operations?
Suppose you are building an internal HR application. The AI agent has the technical capability to onboard or offboard employees. These are high-risk operations with massive financial and security impacts. If a prompt injection attack tricks the agent into offboarding all employees, the result would be catastrophic.
For these sensitive operations, we recommend a protocol called OAuth 2.0 CIBA. CIBA stands for Client-Initiated Backchannel Authentication. Think of it as passkeys for AI agents.
Using standards like CIBA (Client-Initiated Backchannel Authentication), agents can request approval for sensitive operations via push notifications, SMS, or email, even when the user is not actively using the application. (Auth0, Auth0 for AI Agents)
When a user asks the AI agent to do something sensitive, the AI agent evaluates the request. It then calls the Identity Provider to initiate a third-party CIBA flow. This sends a prompt directly to the user's phone, completely outside of the browser context. The prompt will ask: "Do you want to offboard this employee?"
This out-of-band verification is an incredibly powerful security mechanism. It ensures that human authorization is explicitly given for critical actions. It serves as an ultimate layer of protection against jailbreaking. If an attacker injects a prompt to offboard the entire company, your phone will simply buzz with authorization requests that you can easily deny.
Building Secure Architecture by Default
To achieve true agentic runtime security, you must combine dynamic credentials, OAuth 2.0, and CIBA. You write this logic directly into your Python or TypeScript AI applications. The code evaluates JSON Web Tokens, generates dynamic credentials, accesses the required resources, and then automatically revokes those credentials.
Scaling legacy systems into intelligent, AI-driven platforms requires strict architecture governance. You cannot just bolt on security at the end of the development cycle. You must design your AI agents to be secure by default, relying on dynamic intent-bound access rather than static trust. By building these verification loops into your architecture, you empower your organization to adopt Generative AI safely and confidently.
Faisal Feroz is a Chief Technical Architect with over 20 years of experience in modernizing legacy platforms and building resilient enterprise AI systems. He frequently shares deep dives into software architecture and AI safety on his Medium blog and engages with the global engineering community through his LinkedIn profile.
Using CIBA for out-of-band verification is a solid way to stop a system breach. My concern is "authorization fatigue." If an agent is supposed to be autonomous, having it ping a phone for every high-risk move feels like a UX killer. Where do you draw the line on "sensitivity" before these loops become a bottleneck for the automation?
Thanks for sharing this Faisal Feroz , this is great article and nails the point effectively. Context is the key when using AI, not just in development but beyond. While AI is advancing every day without proper context, it will deliver generic output which may not be suited for your organization. However once trained on bulk of corporate data, it will improve alot. But that means organizations will have to dedicate resources to creating bulk of documentation. Nevertheless, there may still be undocumented tacit knowledge. Having said above, AI is still massively helpful in increasing efficiency but with some supervision.