Before an AI agent sends the message

Channel access is only the first decision

An AI support agent may be allowed to draft and send email. That permission answers a narrow question: can this workload use the email tool? It does not establish that every recipient, disclosure, promise, attachment, or instruction inside a particular message is acceptable.

The distinction matters because the final message is where internal context becomes an external commitment. A valid tool call can still reveal private information, make an offer the business cannot honour, follow an instruction planted in retrieved content, or communicate with the wrong destination.

Inspect the message in its real context

A useful runtime check evaluates the proposed action before delivery, while the application still has the authenticated actor, tenant, destination, message body, supporting records, and current policy state. Running that check after the message has left the system turns prevention into incident review.

The inspection should preserve evidence without treating the model as the source of truth. Identity, consent, recipient ownership, contractual limits, and approval requirements must come from server-side application state.

• Inspect customer-controlled input before it enters model context.
• Inspect retrieved text before it is promoted into the prompt.
• Inspect the proposed outbound action before the tool executes.
• Apply deterministic authorization after inspection and before delivery.

Two controls, two different questions

A security decision asks whether the message or its originating context shows signs of manipulation, policy evasion, data exposure, or unsafe action. An authorization decision asks whether this actor may send this exact message to this exact destination now. Neither answer substitutes for the other.

Koreshield provides the security decision and evidence at the input, retrieved-context, and proposed-action boundaries. The application remains authoritative for identity, tenant isolation, business rules, approval, and execution.

Start by observing

Teams should begin in detect mode against representative outbound traffic. Review what the control would have blocked, label false positives and misses, and define the fallback for uncertainty. A useful fallback may remove a suspicious source, produce a read-only response, or route the message to a human reviewer.

Only move a boundary into enforcement when the team has measured its behaviour and tested the failure path. The objective is not to let a detector make business decisions. It is to stop untrusted language from quietly becoming an external action.