What does Redline AI do across the AI agent lifecycle, before deployment and after?

The lifecycle, stage by stage

Redline’s approach follows the agent rather than treating testing, runtime enforcement and monitoring as separate systems. The assembled agent is tested before deployment. Its input boundary is assessed when a live message arrives. Tool calls are checked around each action. Production behaviour is then recorded and analysed after launch.

This structure matters because an AI agent is more than its underlying model. Its behaviour depends on the tools it can call, the MCP servers and skills connected to it, the content it retrieves and the policies applied around those actions. A result from a model-only test does not describe the assembled agent.

The same SDK connects the stages. That allows a finding from pre-deployment testing to inform a runtime rule, while production sessions provide evidence about how the deployed agent behaves. The lifecycle is therefore a continuous control loop: test the assembled system, enforce controls around its actions, observe what happens, and use those observations to refine the controls.

How does Redline test an agent before deployment?

Before release, Redline attacks the assembled agent rather than testing the model in isolation. The test includes the agent’s real tools, MCP servers and skills. Each run takes place in one container, and the result is graded on evidence from the machine.

The test covers 11,204 attack cases across 16 attack families. The relevant question is not simply whether the model produced a refusal. It is whether the attempted behaviour reached the agent’s environment and what the agent actually did there.

This distinction is important for agent security. A model may appear to refuse a request while an attached tool is still called, or it may produce a safe-sounding response while exposing information through an action. Grading on evidence from the machine makes the trace and environment part of the result.

The testing stage identifies several classes of behaviour:

• Injection that lands in the assembled agent.
• Tool misuse.
• Leaked secrets.
• Benign requests that the agent refuses.

A failed run includes the trace. This makes the result useful beyond a test report: it shows the interaction that led to the behaviour and provides a basis for deciding what should be enforced when the agent is live.

Why test the assembly rather than the model?

Attacks land in the tools, MCP servers and retrieved content around a model. A red-team result on the model alone does not describe the agent that users will operate.

Testing the assembly also aligns the assessment with the action surface. If a tool can access order information, send a message or perform another consequential operation, the test needs to observe how the complete agent handles requests involving that tool. The relevant evidence is the agent’s behaviour in its actual environment.

How does Redline assess messages at the input boundary?

At the input boundary of every live conversation, Redline Guard v5 scores each incoming message before the model reads it. This provides an assessment point before the message enters the model’s reasoning flow.

The classifier identifies prompt-injection and harmful messages. Depending on the result, the message can be annotated to the agent or stopped from reaching tools. This boundary is distinct from the controls around tool calls: it addresses the content entering the conversation, while runtime policies govern what the agent is permitted to do.

The input-boundary control does not replace action enforcement. A message may be difficult to classify perfectly, and an agent may encounter unsafe instructions through other parts of its context. For that reason, Redline also evaluates the actions that follow, with policies applied inside the agent process.

The combination gives engineers two relevant observations:

• What entered the conversation before the model read it.
• What the agent attempted to do after processing the conversation.

That separation helps distinguish an unsafe message from an unsafe action. It also means that a tool call can still be checked deterministically, regardless of how the request was worded.

How does Redline block unsafe actions at runtime?

Runtime policies run inside the agent process at four points: pre_input, pre_tool, post_tool and pre_output. They operate when a message arrives, before and after each tool call, and before the agent sends its reply.

A policy can return one of four outcomes:

• Deny.
• Require approval.
• Warn.
• Log.

At the pre_tool stage, the policy sees the tool and every argument before the call. It can deny the call or hold it for a named person’s approval. The agent is told that the call was refused and continues without it.

This creates a control outside the model. The model may propose an action, but the policy evaluates the proposed tool and its arguments before the action is executed. A safeguard that the model can simply be argued out of is an instruction, not a control; deterministic checks provide the enforcement point.

From a test finding to a runtime rule

The same rule can support both pre-deployment testing and production enforcement. Consider an agent that is persuaded to call checkOrderStatus with another customer’s order id. Before release, the behaviour appears as a failed run with the trace attached. After release, a pre_tool rule can deny the call when the order id is not the session’s.

The wording of the message is not the deciding factor at runtime. The check is applied to the tool call and its argument. This allows a finding discovered during testing to become a policy that continues to hold after deployment.

Most rules worth having are written from something a test found. That is why testing and runtime enforcement share one platform: an attack that lands before launch can become the policy that holds after it.

See how to stop unauthorized agent actions and the pre-production testing playbook.

How do honeypot tools expose an agent hijack?

Redline uses honeypot tools that fit the real toolset and that no legitimate conversation calls. If an agent is redirected and calls one of these tools, the call becomes evidence of the redirection.

The honeypot is not presented as a generic external alarm. It is a tool within the agent’s environment, shaped to fit the real toolset. A legitimate conversation should not call it. When it is called, the event is recorded with the session.

This makes a hijack provable through the recorded call rather than inferred only from the agent’s response. The session supplies the surrounding conversation and activity, while the honeypot call identifies the relevant action.

Honeypots therefore complement both red teaming and runtime policies. During testing, they can provide evidence that an attack redirected the agent. After deployment, they can identify a redirected agent in a production session.

What does Redline watch after deployment?

After deployment, Redline records production activity as sessions, evaluates rules against spans, and mines closed sessions for recurring intents. These controls focus on what the agent did for real users, where it broke a rule and what users repeatedly failed to get.

• Sessions. One @observe decorator on the function that handles a message streams every production conversation. The session includes the user’s message, model calls, both halves of each tool call and the reply.
• Violations. Rules match every span as it is written. A broken rule therefore appears on the session where it happened.
• Intents. When a session closes, it is read for recurring user behaviour. This makes visible the requests an agent keeps failing to satisfy.
• Runtime gates. New policies and honeypots reach the running agent within one keepalive, with nothing restarted and no traffic leaving the process.

These records connect an observed event to its context. A violation is not detached from the session in which it occurred, and a tool call is not separated from the message and model activity around it. The result is a production view of the complete interaction.

Intent mining adds a different perspective. Violations show where a rule was broken. Intents show what users keep asking for, including requests the agent repeatedly fails to satisfy. Together, they identify both unsafe behaviour and unmet behaviour.

Changing controls without restarting

A new policy or honeypot reaches the running agent within one keepalive. Nothing restarts, and no traffic leaves the process. This allows runtime safeguards to change while the agent continues running.

The connection is outbound from where the agent runs. Policies are evaluated inside the agent process, so there is no proxy and no endpoint to expose.

How should teams choose red teaming and runtime safeguards?

Four principles help in choosing controls that remain useful across the agent lifecycle.

Test the assembly, not the model

Attacks land in the tools, MCP servers and retrieved content around a model. A model-only result does not describe the assembled agent. Testing should therefore include the components that can change the agent’s behaviour and provide access to actions or information.

Grade on evidence

An agent’s account of its own refusal is a claim. A result backed by the trace and the environment provides evidence of what happened in the machine. This is particularly relevant when the agent’s response and its actions do not align.

Enforce outside the model

A runtime safeguard that the model can be argued out of is an instruction, not a control. Deterministic checks on tool calls and their arguments provide a separate enforcement point. The pre_tool stage is where the tool and every argument can be assessed before execution.

Keep one loop

Findings before launch should become rules after it, on the same agent, without a second integration. Using one SDK across testing, runtime enforcement and production monitoring keeps the tested agent and guarded agent connected.

For how Redline compares with Akto, Prisma AIRS, Noma, Obsidian and AgentWard on exactly these points, see AI agent security platforms compared.

Key takeaways

• Redline tests the assembled agent, including its real tools, MCP servers and skills, rather than the model alone.
• Pre-deployment testing uses 11,204 cases across 16 attack families and grades runs on machine evidence.
• Redline Guard v5 scores every incoming message before the model reads it.
• Deterministic policies run inside the agent process at pre_input, pre_tool, post_tool and pre_output.
• Honeypot tools make a redirected agent provable through a recorded call linked to its session.
• Production sessions, violations and intents connect live behaviour to the controls applied around it.

Common questions

Does Redline only red-team agents before launch?

No. Pre-deployment testing is one stage. After launch, the same SDK records production sessions, evaluates policies around every tool call inside the agent process, scores incoming messages with a prompt-injection classifier and arms honeypot tools. The lifecycle therefore includes testing before release, runtime enforcement and production monitoring after deployment.

Can Redline block an unsafe action at runtime?

Yes. A policy at the pre_tool stage sees the tool and every argument before the call. It can deny the call or hold it for a named person’s approval. The agent is told the call was refused and continues without it, so the action is controlled independently of how the message was worded.

Does the agent have to be redeployed to change a rule?

No. A new policy or honeypot reaches the running agent within one keepalive. Nothing restarts. Runtime gates can therefore be updated for the running agent, and the policies continue to be evaluated inside its process.

Is anything placed in front of the agent’s traffic?

No. The SDK connects outbound from where the agent runs, and policies are evaluated inside its process. There is no proxy and no endpoint to expose. Production conversations are streamed as sessions, while the agent remains in its running environment.

What evidence does Redline use for a failed test?

Redline grades every run on evidence from the machine. A failed run includes the trace, allowing the result to show what the assembled agent did with its tools, MCP servers and skills. This differs from relying only on the agent’s account of its own refusal.

What can production sessions reveal?

A production session records the user’s message, model calls, both halves of each tool call and the reply. Rules match spans as they are written, so violations appear on the session where they occurred. When a session closes, it is read for recurring user behaviour and intents.

Sources

• How to stop unauthorized agent actions
• The pre-production testing playbook
• AI agent security platforms compared