DEV Community: Eray Özer

Why AI Agent Security Needs a Runtime Decision Layer

Eray Özer — Sat, 22 Aug 2026 14:17:19 +0000

AI agents are moving from generating text to taking actions.

They can call APIs, query databases, execute tools, read files, trigger workflows, and interact with production systems.

That changes the security problem.

When an AI system produces an incorrect answer, the impact may be limited to bad information.

When an AI agent executes the wrong tool call, the impact can be much larger.

A useful security question is therefore:

What happens between the moment an agent decides to take an action and the moment that action actually executes?

The missing runtime decision layer

Many agent systems already have controls around prompts, model outputs, application logic, and API permissions.

Those controls are useful.

But there is another important boundary:

the action itself.

A runtime security layer sits between the agent and the system it wants to affect.

AI Agent
    │
    ▼
Runtime Security Layer
    │
    ├── ALLOW
    ├── BLOCK
    └── ESCALATE
    │
    ▼
Tool / API / Database / System

The important property is that the decision happens before execution.

Why allow vs. block is sometimes not enough

A traditional security policy often reduces a request to two outcomes:

ALLOW

BLOCK

That works well when requests are deterministic.

Autonomous agents are different.

Consider an agent attempting:

transfer_funds(
    destination = "new_bank_account",
    amount = "$25,000"
)

This action may be legitimate.

It may also be dangerous.

Automatically allowing it could create unnecessary risk.

Automatically blocking it could break a legitimate workflow.

This is where a third state becomes useful:

ESCALATE

The action can be paused and sent to a human reviewer.

The resulting decision model becomes:

Decision	Meaning
ALLOW	The action is safe and policy-compliant.
BLOCK	The action clearly violates policy or matches a known dangerous pattern.
ESCALATE	The action is ambiguous or high-risk and requires human judgment.

Runtime enforcement changes the security boundary

A runtime layer can evaluate more than the text of the prompt.

Depending on the architecture, useful signals can include:

Agent identity
Tool permissions
Resource scope
Data sensitivity
Session context
Rate limits
Previous actions
Known attack patterns
Policy violations

That changes the question from:

"Was the model response safe?"

to:

"Is this agent allowed to perform this specific action against this specific resource right now?"

That is a much stronger enforcement boundary.

Human review should handle the ambiguous tail

Human review is expensive.

Sending every agent action to a person defeats much of the purpose of autonomous systems.

A better model is to let deterministic decisions handle the obvious cases and reserve human review for the ambiguous cases.

Clear + safe
     │
     ▼
   ALLOW


Clear + dangerous
     │
     ▼
   BLOCK


Ambiguous / high-risk
     │
     ▼
 HUMAN REVIEW

This creates a useful principle:

Automate the obvious. Block the dangerous. Escalate the ambiguous.

What should a runtime security layer provide?

1. Deterministic policies

Developers should be able to understand why an action was allowed or denied.

Policies should be explicit enough to inspect, test, and modify.

2. Runtime enforcement

A policy is much more useful when it actually controls execution rather than simply producing a warning after the action has happened.

3. Context-aware decisions

The same action can have very different risk depending on:

Which agent requested it
Which tool is being called
Which resource is affected
What happened earlier in the session
What type of data is involved

4. Human escalation

Some decisions genuinely require context that cannot be represented as a simple binary rule.

A good architecture should make human review an exception rather than the default.

5. Auditability

Every security decision should leave enough information to answer:

What did the agent attempt?
What policy was evaluated?
What signals were detected?
What decision was made?
Why was that decision made?

Without this information, investigating an incident becomes much harder.

Prompt injection is only part of the problem

Prompt injection gets a lot of attention in agent security, and for good reason.

But preventing malicious instructions from changing model behavior does not automatically solve the next problem:

What happens when the agent is allowed to perform a powerful action?

An agent can behave exactly as intended and still have too much authority.

For example:

User request
     ↓
Agent reasoning
     ↓
Tool call
     ↓
Production database

The security boundary should not disappear between the model and the tool.

A stronger architecture adds an explicit enforcement layer:

User request
     ↓
Agent reasoning
     ↓
Runtime policy
     ↓
ALLOW / BLOCK / ESCALATE
     ↓
Tool call
     ↓
Production system

The practical challenge

The difficult part is not creating three labels.

The difficult part is building reliable policies and signals that produce useful decisions without creating excessive false positives.

A system that blocks everything is secure in theory but unusable in practice.

A system that allows everything is convenient but dangerous.

The real engineering challenge is finding the right balance.

That means measuring things such as:

False-block rate
False-allow rate
Escalation rate
Decision latency
Review time
Policy coverage
Detection quality

And those measurements should be reproducible.

Where agent security is heading

As AI agents gain access to more tools and infrastructure, the security model around them will need to evolve.

The key question will increasingly be not just:

"What did the model generate?"

but:

"What is the agent actually allowed to do?"

That requires an enforcement boundary between intention and execution.

The agent can remain autonomous.

Its authority does not have to be unlimited.

Don't just secure the model. Secure the action.

AI assistance disclosure: This article was created with AI assistance and reviewed and edited by the author for accuracy and completeness.

Why Traditional API Gateways Fail Autonomous AI Agents (And How We Fixed It)

Eray Özer — Fri, 07 Aug 2026 13:29:27 +0000

We are moving rapidly from experimental chat interfaces (like ChatGPT wrappers) into the era of fully autonomous AI agents. These agents don't just generate text; they are granted direct access to enterprise APIs, internal databases, and execution environments.

But as engineering teams rush to deploy agentic workflows, a massive architectural blind spot is emerging: Runtime Security.

The Problem: Legacy Middleware Chokes the Agent Loop

Most enterprises attempt to secure AI agents by hiding them behind traditional API gateways or static Web Application Firewalls (WAFs). Here is why that approach breaks down in production:

Semantic Blindness: A traditional firewall looks for SQL injections (DROP TABLE) or specific malicious headers. It has no idea what to do with a semantic prompt injection hidden inside a natural language payload.
Unacceptable Latency: Autonomous agents often run multi-step reasoning loops (like ReAct). If you route every single tool-call and LLM response through a heavy external governance middleware, you introduce massive latency overhead. The agent loop chokes.
Silent PII Leaks: Agents often scrape or process vast amounts of unstructured data. Traditional DLP (Data Loss Prevention) tools are too slow to intercept and redact Personally Identifiable Information (PII) on the fly before it hits an external LLM provider.

Enterprise AI needs a new kind of defense layer. It needs to be incredibly fast, context-aware, and deployed directly alongside the agent.

Enter Aegisora: A Zero-Latency Runtime Proxy

To solve this, we built Aegisora—an open-source, zero-latency governance and proxy layer designed specifically for autonomous AI agents and AppSec teams.

Instead of relying on bloated external middleware, Aegisora sits directly between your agents and your LLM endpoints. It acts as a narrow control plane that provides:

Real-time Interception: Inbound prompts and outbound tool-calls are scanned instantly to detect adversarial patterns and prompt injections.
On-the-fly PII Masking: Automatically detect and redact sensitive corporate assets (SSNs, API keys) before the payload ever reaches external endpoints like OpenAI or Anthropic.
Least-Privilege API Access: Human-in-the-loop protocols for high-stakes decisions, ensuring agents can't execute unauthorized API bursts.
Zero-Latency Overhead: Built for speed, ensuring your agent's reasoning loops remain fast and uninterrupted.

Let's Build Secure AI Together 🛡️

Security in the age of autonomous agents shouldn't be a black box controlled by a few massive vendors. We believe the future of AI governance is open-source.

We are building Aegisora in public and we need the community's help to stress-test the architecture, break the proxy, and improve the runtime defenses.

Check out the architecture and drop a star on our GitHub repo:
👉 Aegisora GitHub Repository

How is your team handling runtime validation for AI agents? Let’s discuss in the comments below!

How to Build Resilient AI Agents: Stop Flaky LLM Calls from Crashing Your App 🛡️

Eray Özer — Fri, 03 Apr 2026 15:03:26 +0000

Building autonomous agents with LLMs is exciting, but let's be honest: external APIs are unpredictable.

You've probably seen your agentic workflow crash because of a random TimeoutError, a ConnectionError, or the dreaded Rate Limit. In production, "trying again manually" isn't an option.

Last night, I built and released Veridian Guard — a lightweight, zero-dependency safety layer designed specifically to handle these failures gracefully.

The Problem: Flaky APIs & Bloated Code

Traditionally, you'd wrap every call in a try-except block with a while loop for retries. It works, but it makes your code messy and hard to maintain — especially when dealing with complex asynchronous agent frameworks like LangChain or CrewAI.

The Solution: Veridian Guard 🌿

Veridian Guard provides a robust @guard decorator that manages retries, delays, and fallbacks with just one line of code.

🚀 Quick Start


bash
pip install veridian-guard
Wrap any flaky function, and it's protected:
from veridian.guard import guard
import random

@guard(max_retries=3, delay=1.0, fallback="Default safe response")
def call_llm_agent():
    if random.random() < 0.7:
        raise ConnectionError("LLM API Timeout!")
    return "Agent succeeded!"

print(call_llm_agent())

⚡ Seamless Async/Await Support
One of the features I'm most proud of is its automatic detection. Whether your function is synchronous (def) or asynchronous (async def), Veridian Guard knows exactly how to handle it. No extra configuration needed.
import asyncio
from veridian.guard import guard

@guard(max_retries=3, delay=2.0, fallback={"status": "failed"})
async def fetch_data_from_llm():
    await asyncio.sleep(1)
    raise TimeoutError("API is too busy!")

async def main():
    result = await fetch_data_from_llm()
    print(result)  # Output: {'status': 'failed'}

asyncio.run(main())

✨ Why Veridian Guard?
Zero Dependencies — Pure Python. Keeps your environment clean and lightweight.
Smart Logging — Automatically logs failed attempts so you can monitor where your agent is struggling.
Fail-Safe Fallbacks — Ensure your main application loop never crashes again.
Error Tolerance — Focus on the logic; let Guard handle the instability.

🛠️ Get Involved
I built this to solve a real pain point in my own AI projects at Vyno AI, and I hope it helps the community build more reliable autonomous systems.
I'd love to hear your feedback, suggestions, or see your contributions!

⭐ GitHub:(https://github.com/ozereray/veridian)
📦 PyPI: veridian-guard

Happy coding! 🌿🛡️