The Agentic Security Problem Has Two Sides. Only One Is Well Understood. 

Securing production agents requires controlling what reaches the model and containing what happens when the model acts. Ignore either side and you leave the system exposed.

The pressure on every IT organization right now is to connect agents to real systems, the ticket queue, the ERP estate, the document store, the terminal. Because an agent sealed off from all of that is a demo. The connection is what creates enterprise value, it is also what creates risk. Once an agent can access private data, consume information your organization does not control, and take action, including external communication, securing the model itself is no longer enough. 

In essence this is a problem with two inseparable sides

1. What reaches the model, and what it is allowed to do. A model cannot tell your instructions apart from an instruction hidden in a ticket, an email or a document: it receives them as one stream. You control what reaches it, settle who it is working for before it reads a word, and decide in advance which tools, data and approvals that identity carries. (There Is No Firewall for a Sentence)
2. What happens when the model acts, including when something goes wrong. Assume something gets through eventually, because it will. Then the question is how far it gets: what its code can touch, where it can send anything, what credentials survive the run, and how much damage is reachable at all. (Assume the Model Is Compromised)

Input controls without containment leaves you trusting a filter. Containment without input controls leaves you cleaning up attacks you could have stopped. The two sides are not equally mature. Input defense is comparatively well developed; containment is younger, and some of its managed components leak more than their documentation admits, which is why the second paper is equally important. The first paper’s conclusion is blunt about the premise: “You cannot make the model itself safe.” The second picks up exactly there: “A compromised model is never harmless, whatever a vendor tells you.”

We learned this by putting agentic technology into production

We did not set out to write about AI security. We set out to put an AI copilot, LuumenAI, into production against SAP and ERP estates. It reads alerts, incidents and tickets, and can act on what it finds. That forced us to confront the same question every enterprise deploying agents eventually faces: How much authority can you safely give a model you cannot fully trust? 

Our first iteration gave the model a large set of tools and a lot of latitude, based on the reasonable-sounding assumption that a capable model would use them sensibly. Production taught us otherwise. Most of the architecture in these two papers came from taking that latitude away a piece at a time, and finding out what each piece cost. Some of that latitude did not come back as code. It came back as a person signing off. The papers are the record of that work, including the parts we walked back.

The papers are grounded in a simple production reality: prompt injection is not a solved problem, so a production architecture cannot depend on stopping every attack. It has to assume something eventually gets through and make sure the consequences are bounded. That premise became even harder to ignore during the July 2026 disclosures from Hugging Face, OpenAI and Anthropic, which showed how agentic systems can exploit gaps in boundaries their operators expected to hold. The second paper is about designing for that failure before it happens.

Five questions every enterprise deploying agents should be able to answer

These are the questions the two papers are built to settle. If several are live for you right now, they are worth an hour of your time.

• Who or what can put untrusted information in front of our agents?
• What data, systems and tools can each agent actually reach?
• If an agent is compromised, how far can it get?
• Which actions require a human before they become irreversible?
• Can we prove those boundaries to a customer, auditor or regulator?

Production security requires both

If the work so far has gone into filtering what the model reads, you are trusting a filter that only has to fail once. If it has gone into sandboxing what the model runs, you are containing attacks you may have been able to stop earlier. Neither is enough on its own. And for the agents actually worth running, even both halves together leave some decisions that still belong to a person.

Which agents in your estate can reach private data, read text written outside your company, and send information out — all three at once? And who signs off when one of them does something that cannot be undone?

There Is No Firewall for a Sentence covers the controls before and around the model: provenance, authorization, untrusted input, tool scope, memory and approval. Assume the Model Is Compromised picks up where those controls necessarily stop: execution boundaries, egress, credentials, isolation, and limiting the blast radius.

Read together, they are not a theoretical model for securing agents. They are controls that survive production.

Read the two papers. Then pressure-test your own environment.

If you cannot readily answer which agents can access private data, consume untrusted content and take consequential action, that is where we recommend starting.

In an apiphani AI Workshop, we work with your team to map your highest-value agentic opportunities against the controls they require: what each agent can reach, what it can read, what it can do, where the material risks sit and where human approval belongs.

You leave with a prioritized view of where agentic technology can create value, where risk needs to be designed out, and what is worth building first.

About the Author

Josh Greenwell

Staff Applied AI Engineer at Apiphani