How to Build a Lifecycle-Aware AI Security Engine

The wrong mental model: one giant AI firewall

The simplest AI security design is also the least realistic. Teams put one classifier or one ruleset in front of the model and expect it to answer every question: should the request be allowed, is the prompt malicious, is the user authorized, is the output safe, will the request break budget, and can the model call tools?

That does not work because those questions appear at different times.

• A network rule can run before auth.
• An access-grant decision needs caller identity and the selected resource.
• A token or cost gate needs model and token-envelope context.
• A prompt-safety check needs the decoded prompt text.
• A response-leakage check needs the provider output.
• A final cost reconciliation needs the request to finish.

Once you accept that timing reality, the architecture changes. You stop looking for one magical AI firewall and start building staged enforcement.

What recent guidance implies for engine design

The best public signal here is not one single framework. It is the overlap across several sources.

On January 2024, NIST published Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. The report matters because it frames AI security across lifecycle stages, attacker goals, attacker capabilities, poisoning, privacy attacks, model extraction, and generative AI prompt-injection variants. That is already a staged way of reasoning.

On March 12, 2025, OWASP's updated Top 10 for LLM and GenAI apps made the same point from the application side. Prompt injection, sensitive information disclosure, improper output handling, excessive agency, and unbounded consumption are different failure classes. No single gate can see them all with the right context.

On May 25, 2026, OWASP's AIUC-1 crosswalk for agentic applications pushed the architecture further by calling out gaps around agent identity, runtime containment, architectural monitoring, supply-chain attestation, and schema controls. That is effectively a warning against thin, single-stage security.

Taken together, the guidance says a real AI security engine needs:

• staged controls
• capability-aware access boundaries
• response-side handling, not only input-side filtering
• cost and abuse controls in the runtime path
• evidence and monitoring after the decision

The stages a real AI security engine needs

Here is the practical shape of a production-ready engine.

1. Request-aware admission controls. These handle IP policy, payload size, request rate, concurrency, and other cheap protections before expensive work starts.

2. Identity and access controls. These answer who is calling, which virtual key or tenant is behind the request, and whether that identity can reach the chosen model or MCP server.

3. Resource and token-aware controls. These reason about the selected model, token envelope, budgets, quotas, and other usage boundaries that depend on decoded request context.

4. Request-side content controls. These inspect prompt text, redact sensitive input, detect prompt injection or jailbreak patterns, and decide whether upstream execution should continue.

5. Tool and plugin controls. These apply explicit capability rules to MCP tools or other extension points so the model cannot turn a weak prompt into a strong action path.

6. Response-side controls and evidence. These inspect model output for leakage or unsafe content, redact when appropriate, block when necessary, and record enough evidence for operators to understand what happened.

That sequence is not overengineering. It is the minimum structure required to answer different security questions with the right data.

How Odock compares

At Odock, our runtime follows almost exactly this staged pattern. Our lifecycle runs through request-aware gates, identity and access gates, resource-aware gates, token and cost gates, request-side safety, plugin gates, upstream execution, response-side safety, post-upstream plugin gates, response writing, and final usage evidence.

SafetySec then handles the content-aware parts of that flow. In SafetySec, we handle:

• prompt-injection detection
• jailbreak-pattern detection
• sensitive redaction
• data-leakage detection
• repeated-risk awareness
• safety evidence

That is an important design choice. SafetySec does not replace access control, budgets, quotas, or MCP capability policy. It handles prompt and response safety while other guardrails handle traffic shape, access, and resource boundaries.

The mapping is straightforward:

• Early request controls:

We stop abuse before expensive work starts with request-aware gates for origin, payload, rate limits, and concurrency.

• Identity-aware permissions:

We keep model and tool access attached to principals through explicit access grants for models and MCP servers.

• Token and cost enforcement:

We prevent denial of wallet and runaway usage with token gates, budgets, quotas, and lifecycle reconciliation.

• Request-side prompt defense:

We stop unsafe input before upstream execution with SafetySec request-side prompt-risk checks and input redaction.

• Tool capability governance:

We limit what agents can actually do with MCP allowed tools, blocked tools, scopes, and semantic filters.

• Response-side defense:

We catch leakage or unsafe output before the caller sees it with SafetySec response-side leakage checks and output redaction.

• Evidence and audit:

We make decisions explainable and monitorable with safety evidence plus usage, status, cost, and latency recording.

Why this is stronger than app-level filters

App-level filters are not useless. They are just not enough as the main control surface.

In distributed AI systems, app-level security drifts quickly:

• different services implement different rules
• teams release at different speeds
• tool access gets added before platform review
• logging shapes diverge
• cost limits become best-effort instead of enforced limits

A lifecycle-aware gateway approach fixes the control point. Product teams still ship features, but the highest-risk enforcement stays in shared infrastructure.

That is especially important for agentic systems. The moment a model can call a repository tool, a browser tool, a ticketing tool, or an internal action, the blast radius stops being "bad text" and starts being "real side effects." That is where staged enforcement matters.

The realistic boundary of the engine

Even a good security engine is not the whole program. At Odock, we do not overstate this.

You still need adjacent work for:

• secure development and patching of MCP servers and plugins
• supply-chain controls for models, datasets, and dependencies
• architecture reviews for high-risk workflows
• schema validation and business-rule validation inside tool handlers
• release governance, evaluation, and red-teaming outside the live request path

But if the runtime layer is weak, those other controls are forced to compensate for the wrong problem. The runtime path is where requests become actions, costs, and outputs. That is why the engine design matters so much.

Sources

• NIST AI 100-2e2023: Adversarial Machine Learning, January 2024
• OWASP Top 10 Risk & Mitigations for LLMs and Gen AI Apps, 2025
• OWASP AIUC-1 Crosswalks for Agentic Applications, May 25, 2026
• OWASP State of Agentic AI Security and Governance 2.01, June 1, 2026
• Odock Runtime Enforcement
• Odock Security Engine
• Odock Guardrail Modules