DEV Community: Amer Yahya

𝗧𝗵𝗲 𝗮𝗴𝗲𝗻𝘁 𝗱𝗲𝗹𝗲𝘁𝗲𝗱 𝘁𝗵𝗲 𝗿𝗲𝗰𝗼𝗿𝗱. 𝗧𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗽𝗿𝗼𝗺𝗽𝘁 𝘀𝗮𝗶𝗱 𝗻𝗼𝘁 𝘁𝗼

Amer Yahya — Fri, 05 Jun 2026 10:58:28 +0000

Prompt engineering is not a security boundary. Here is why that matters for everyone building production agents.

When your AI agent calls an MCP tool, it sends a structured message with a tool name and parameters. The model decided what to call and what to pass in. That decision came from the model, shaped by context it accumulated across a session.

Your system prompt did not validate those parameters. It did not check whether the tool call was permitted at that moment, for that user, under that workflow. It did not require approval before the action fired. It did not write an audit entry.

This is the gap:

In a traditional app, you enforce access control at the API layer. Tokens, scopes, middleware, rate limits. The business logic does not get to decide its own permissions at runtime.

In most agentic apps right now, the agent is deciding its own permissions dynamically, constrained only by what you wrote in the system prompt. That is a significant gap.

What you actually need is a layer that sits between the agent and the tools, evaluating every call against a defined policy before it executes.

That means:

Tool-level allow/deny rules
Parameter schema enforcement
Context-aware approval flows for high-risk actions
Immutable audit logs of what was called, with what, and by which agent

This is not a new idea. It is how we have handled access control in every prior compute paradigm. Agents need it too.

This is what Enforra is building: a runtime control layer that enforces what agents can do, not just what we hoped they would do.

Website: https://www.enforra.com/
GitHup: https://github.com/enforra/enforra/

Prompt Engineering Is Not a Security Boundary

Amer Yahya — Fri, 05 Jun 2026 10:53:57 +0000

This is a deep technical article on why prompt engineering for AI agents fails as a security boundary, written for advanced AI engineers and developers.

Teams building AI agents discover, usually after something breaks, that their system prompts were never actually enforcing anything. They were shaping behavior. Shaping is not enforcement. The distinction matters enormously once your agent has real tool access.

This article is about what that distinction means technically, why it exists, and what a proper enforcement layer actually looks like.

Prompt Engineering Is Not a Security Boundary

Prompt Engineering Is Not a Security Boundary Why agentic systems need runtime policy enforcement, not better instructions There is a pattern emerging in production agentic systems that deserves serious engineering attention. Teams building AI agents discover, usually after something breaks, that th

linkedin.com

AI Agents: Runtime Control vs Static Guardrails

Amer Yahya — Thu, 04 Jun 2026 15:41:29 +0000

Your AI agent just sent an email you did not approve.

That is not a hypothetical. That is what happens when an agent has tool access and no runtime controls.

Most people building agents today have guardrails at the model level. Output filters. Prompt restrictions. These handle what the agent says.

But once an agent has tools, the dangerous surface is not its output. It is its actions.

Calling an API. Writing to a database. Triggering a webhook. Interacting with an MCP server. Sending a message. Modifying a file.

These are not content problems. They are authorization problems.

Runtime control means the agent checks policy before it acts. Not after. Not sometimes. Every tool call, every action, every time.

That is the infrastructure gap we are solving at Enforra.

Guardrails at the model layer are necessary. They are not sufficient. Not for agents that do things.

Website: https://www.enforra.com/
GitHup: https://github.com/enforra/enforra

AI Agents and Static Guardrails

Amer Yahya — Thu, 04 Jun 2026 15:39:47 +0000

There is a concept gap in the current AI agent stack.

Most teams apply safety at the model layer: system prompts, output filters, content policies. These work fine when the agent is generating text. They break down when the agent is executing.

The problem space looks different at runtime:

Your agent calls a tool. Which tools are allowed? With what parameters? Under what conditions?

Your agent wants to send a message, write to a database, trigger an API, or interact with an MCP server. Who decided those actions were permitted? How is that policy defined? How is it enforced? How is it audited?

Right now, most teams handle this with a mix of prompt instructions, hard-coded checks, and hope. That is not governance. That is technical debt with a timer on it.

Runtime control is a policy enforcement layer that sits between the agent and its tools. It evaluates each action against a defined policy before execution, routes sensitive actions for human approval, and logs everything.

It is closer to an authorization layer than a safety filter.

This is what Enforra is building. Not another wrapper around a language model. An infrastructure primitive for the agentic stack.

If you are working on agent frameworks, MCP tooling, or production agentic systems and want to think through this, I am happy to talk.

Website: https://www.enforra.com/
GitHup: https://github.com/enforra/enforra

Runtime Control vs Static Guardrails in Agentic Systems

Amer Yahya — Thu, 04 Jun 2026 15:37:32 +0000

Most AI agent security conversations are about preventing bad outputs.

That is the wrong problem.

The real problem is not what an agent says. It is what an agent does.

There is a meaningful difference between static guardrails and runtime control.

Static guardrails sit at the model layer. They shape how a model responds. They are useful for content policy, tone, and output filtering. But they were built for a world where AI generates text, not one where AI takes actions.

Runtime control is different. It sits between the agent and the outside world, at the moment of execution. It governs what tools the agent can call, what parameters are allowed, which actions require human approval, and what gets logged.

When an agent can send emails, query databases, trigger webhooks, write to files, or interact with MCP servers, static guardrails are not enough.

You need a layer that enforces policy at the point of action.

That is what we are building at Enforra.

Not a content filter. A control layer.

The agents are getting more capable. The actions are getting higher stakes. The infrastructure to govern those actions needs to exist before something goes wrong, not after.

If you are building AI agents that touch real systems, the question is not whether you need runtime control. It is whether you have it yet.

website: https://www.enforra.com/
GitHup: https://github.com/enforra/enforra

Runtime Control vs Static Guardrails in Agentic Systems

Amer Yahya — Thu, 04 Jun 2026 15:34:21 +0000

The guardrail model that shaped early LLM deployment is quietly becoming inadequate. This article examines why, what the architectural gap looks like at the execution layer, and what a more complete control model for agentic systems requires.

Runtime Control vs Static Guardrails in AI Agent Systems

Runtime Control vs Static Guardrails in AI Agent Systems Why Build-Time Constraints Are Not Enough for Production Agents Static guardrails were a reasonable first answer to agent safety. They are not a complete one.

linkedin.com

AI Agents and Runtime Permissions

Amer Yahya — Wed, 03 Jun 2026 10:35:18 +0000

AI agents are no longer just generating text.

They are starting to call tools, access data, use APIs, interact with MCP servers, send messages, update records, trigger workflows, and touch real business systems.

That changes the security model.

A chatbot that gives a bad answer is one problem.

An agent that calls the wrong tool, sends the wrong message, updates the wrong customer record, or triggers the wrong workflow is a very different problem.

This is why runtime permissions matter.

Agents should not have unlimited access just because they were given a system prompt.

They need clear controls during execution:

Which tools can this agent call?

What parameters are allowed?

Which actions require human approval?

What data can the agent access?

What should be blocked before it happens?

What needs to be logged for review?

System prompts help guide behavior, but they are not a security boundary.

Once agents can take actions, permissions need to move closer to runtime.

That is the layer Enforra is focused on.

Enforra is a runtime control layer for AI agents. It helps developers define what their agents are and are not allowed to do before tool calls, MCP actions, and sensitive workflows become security problems.

The future of AI agents is not just smarter models.

It is controlled execution.

website: https://www.enforra.com/
GitHub: https://github.com/enforra/enforra

Why AI Agents Need Runtime Permissions

Amer Yahya — Wed, 03 Jun 2026 10:32:33 +0000

This article is for technical builders, advanced AI engineers, and anyone building agents.

The core thesis:

AI agents are becoming action-taking systems.

They will increasingly operate across tools, APIs, files, databases, SaaS applications, MCP servers, internal workflows, and infrastructure.

That means the security model needs to move from prompt-only guidance to runtime enforcement.

Prompts can describe what the agent should do.

Runtime permissions define what the agent is allowed to do.

For production agents, that distinction matters.

The future of AI agent infrastructure will not only be about better reasoning, longer context windows, or more capable tools.

It will also be about controlled execution.

Because once agents can act, permission becomes part of the runtime.

Why AI Agents Need Runtime Permissions

AI agents are moving from text generation into execution. The early interaction model for LLM applications was mostly request and response.

linkedin.com

How to Secure Your MCP Agent

Amer Yahya — Tue, 02 Jun 2026 15:49:56 +0000

This is a comprehensive technical article for AI engineers and system architects.

It breaks down how to secure MCP agents at the runtime layer, from tool permissions and parameter validation to human approvals, audit logs, sandboxing, and policy enforcement before actions execute.

The Model Context Protocol, or MCP, is becoming one of the most important interfaces in the AI agent stack. It gives agents a standardized way to connect with tools, APIs, files, databases, SaaS systems, and internal services.

How to Secure Your MCP Agent

linkedin.com

Your AI agent should not be allowed to do everything just because it can.

Amer Yahya — Tue, 02 Jun 2026 15:33:29 +0000

When AI agents were mostly text generators, the main failure mode was bad output.

Now agents are becoming execution systems.

They call tools.
They invoke APIs.
They interact with MCP servers.
They read and write data.
They trigger workflows.
They modify state.

That creates a different class of risk.

The question is no longer only:

“Did the model answer correctly?”

The question becomes:

“Was this agent allowed to take this action, with these parameters, in this context, at this moment?”

That is a runtime permissions problem.

For production agents, control needs to happen before execution, not only after logs are reviewed.

A serious runtime layer should be able to evaluate:

• Tool-level permissions
• Parameter-level constraints
• MCP action policies
• Sensitive workflow approvals
• Data access boundaries
• Human-in-the-loop rules
• Audit logs for every meaningful action

System prompts are useful, but they are not enough.

They describe intended behavior.

They do not reliably enforce execution boundaries.

This is the thesis behind Enforra.

As agents become more capable, developers need a lightweight control layer that sits between the agent and the action, enforcing what the agent can and cannot do at runtime.

The next phase of agent infrastructure will not just be about orchestration.

It will be about governed execution.

website: https://www.enforra.com/
GitHub: https://github.com/enforra/enforra

Why AI agents need runtime permissions?

Amer Yahya — Mon, 01 Jun 2026 13:06:16 +0000

When AI agents were mostly text generators, the main failure mode was bad output.

Now agents are becoming execution systems.

They call tools.
They invoke APIs.
They interact with MCP servers.
They read and write data.
They trigger workflows.
They modify state.

That creates a different class of risk.

The question is no longer only:

“Did the model answer correctly?”

The question becomes:

“Was this agent allowed to take this action, with these parameters, in this context, at this moment?”

That is a runtime permissions problem.

For production agents, control needs to happen before execution, not only after logs are reviewed.

A serious runtime layer should be able to evaluate:

System prompts are useful, but they are not enough.

They describe intended behavior.

They do not reliably enforce execution boundaries.

This is the thesis behind Enforra (enforra.com).

As agents become more capable, developers need a lightweight control layer that sits between the agent and the action, enforcing what the agent can and cannot do at runtime.

The next phase of agent infrastructure will not just be about orchestration.

It will be about governed execution.

GitHub: github.com/enforra/enforra

Your AI agent should not be allowed to do everything just because it can

Amer Yahya — Mon, 01 Jun 2026 12:59:21 +0000

That is one of the biggest problems with many agentic systems today.

We give agents access to tools, APIs, files, databases, MCP servers, messaging systems, and internal workflows.

Then we rely heavily on prompts to control what they should or should not do.

That works until the agent takes an action it was not supposed to take.

For example:

Calls the wrong tool
Uses the wrong parameter
Sends the wrong message
Accesses the wrong data
Triggers the wrong workflow
Modifies the wrong record

This is why AI agents need runtime permissions.

Not just instructions.

Not just observability.

Not just logs after something has already happened.

Agents need a control layer that checks actions before they execute.

At runtime, the system should be able to answer questions like:

Is this agent allowed to use this tool?
Is this action safe in this context?
Are these parameters permitted?
Does this action require human approval?
Should this action be blocked?
Should this action be logged?

This matters because once agents move from chat responses to real actions, prompts are no longer enough.

A system prompt can tell an agent not to do something.

But a runtime control layer can stop the action before it happens.

That difference matters.

For production agents, the control layer should sit between the agent and the tools it wants to use. Every tool call, MCP action, sensitive workflow, or external action should be checked against policy before execution.

This is where we are focused with Enforra (enforra.com).

Enforra is a lightweight runtime control layer for AI agents. It helps developers enforce tool permissions, MCP controls, approval workflows, parameter-level policies, and audit logs before agent actions become security problems.

The future of AI agents is not just autonomy.

It is controlled autonomy.

GitHub: github.com/enforra/enforra