Promptective journal / Guide

LLM security in production

Safer inputs, retrieval, outputs and tools.

A compact production model server stands inside nested cobalt, smoked-glass and aluminium control trays
Production security starts with a deliberate boundary around what enters the model and what leaves it.

LLM security protects the full data and action flow around a model. Inspect untrusted input and retrieval, validate output, keep tool authority narrow, minimise sensitive telemetry and prepare for failures. No single detector covers identities, providers, data sources, plugins and tools.

Main LLM security risks

The OWASP GenAI LLM Top 10 2026 provides a current risk catalogue. The NIST Generative AI Profile covers lifecycle governance, testing, monitoring and incident response.

  • Prompt injection: user or retrieved content tries to override trusted instructions.
  • Sensitive information exposure: prompts or responses reveal credentials, personal information or private context.
  • Unsafe output handling: generated code, HTML or commands reach another component without validation.
  • Excessive agency: an agent can read, write, send or delete beyond the user's authority.
  • Retrieval and supply-chain compromise: poisoned content, models or dependencies influence the application.
  • Unbounded consumption: crafted requests exhaust tokens, tools, time or spend.
  • Confabulation: plausible false output drives a consequential decision.

A guarded production request path

1

Client

Bind the request to an authenticated user, application and environment.

2

Security gateway

Normalise inputs, inspect content and enforce organisation policy.

3

Scoped LLM

Expose only the context, data and tools required for the task.

4

Output control

Verify responses and actions before delivery or execution.

Monitoring spans the path and records bounded decision evidence, while alerts surface policy failures without requiring a raw conversation archive.


Production control stack

  1. Inventory every AI path: owner, purpose, model, provider, identity, data, tools and environment. Include Shadow AI.
  2. Classify and minimise data: define what may enter each provider and remove unnecessary fields.
  3. Separate instruction from data: preserve provenance for uploads, retrieval and tool results; keep policy outside user-editable context.
  4. Inspect both directions: detect injection and sensitive input before forwarding; validate and redact output before delivery or execution.
  5. Authorise tools outside the model: check identity, operation, resource, arguments and approval in deterministic code.
  6. Bound use: limit payloads, tokens, time, retries, calls, concurrency and spend.
  7. Retain content-minimised evidence: record findings, decisions and delivery state; make raw content a reviewed exception.
  8. Test after material change: re-evaluate models, prompts, retrieval, tools and policy.

Normal authentication, encryption, secrets management, patching, segmentation and supply-chain controls still apply. The AI security boundary guide, application protection guide, prompt injection guide and 15 prompt injection examples with layered defences cover these paths in more detail.

Inspect both sides of inference

Before the model

Bound size, normalise formats, classify content and detect attack indicators.

After the model

Check sensitive data, policy violations, expected structure and proposed actions.

Input controls reduce malicious context. Output controls reduce leakage and unsafe delivery. Neither can substitute for the other.


Secure retrieval, output and tools

Retrieved internal content remains untrusted data. Keep its source and access scope attached, prevent it from redefining policy and verify citations against underlying sources for high-risk decisions.

Validate output for its destination: strict schemas for structured data, context-specific encoding, secret and personal-information checks, and human review where residual risk is unacceptable. Treat generated URLs, code and attachments as untrusted.

The ASD Australian Cyber Security Centre's AI data security guidance recommends minimisation, access controls, encryption, provenance, integrity checks, continuous assessment and secure deletion.

Give agents narrow typed operations. Scope reads to existing access; validate exact write targets; preview external recipients; bind approvals to privileged actions, arguments, identity and expiry; isolate code execution with filesystem, network, time and resource limits. See the AI agent security guide.

Give tools narrow contracts and bounded authority

Operation

Separate read, write, delete and execute permissions.

Scope

Bind access to specific resources, destinations and identities.

Approval

Pause high-impact calls with the exact arguments visible.

Sandbox

Restrict network, filesystem, credentials, time and compute.

Tool security combines explicit operations, scoped resources, approval rules and isolated execution.


Compare AI guardrails by deployment and evidence

Choose guardrails around the paths your organisation needs to govern: application inputs and outputs, retrieved content, workforce AI use and agent actions. Map each path to the component that inspects it and the point where policy can stop delivery or execution.

F5 AI Guardrails

F5 AI Guardrails documents runtime controls for models, applications and agents, including prompt-injection defence, sensitive-data protection, output moderation and controls on agent actions and tool use. Its documented deployment options include public and private cloud, on-premises and fully air-gapped environments.

F5 also describes logging system prompts, instructions and tool calls. Ask which content the selected configuration collects, which logging controls are available and how access, retention and deletion work.

Check Point AI Guardrails and Lakera Guard

Check Point AI Guardrails, identified as Lakera Guard in its privacy data sheet, documents direct and indirect prompt-attack defence, data leakage prevention, content moderation and agent behaviour controls. Check Point also describes workforce AI controls; confirm which product and deployment cover each employee workflow.

The privacy data sheet distinguishes cloud-hosted processing from on-premises or private-cloud self-hosting. It describes controls to disable or restrict retention of pseudonymised prompts in the cloud service. Confirm the scope of those controls and any agreed support access for the chosen deployment.

Use the same pilot questions

  • Coverage: which applications, versions, transports, inputs, outputs and tool actions does the selected deployment inspect?
  • Enforcement: where does a denial stop delivery or execution, and what happens when inspection is unavailable?
  • Data handling: where is content processed, what is retained, who can access it and how is it deleted?
  • Evidence: can the resulting records identify the policy, finding, decision and delivery outcome while minimising sensitive content?

For Australian deployments, confirm processing regions and cross-border handling in the contract. Test allowed requests, blocked requests and outages on the exact paths you intend to deploy. Compare Promptective's supported AI coverage and routine evidence boundary against the same requirements.

Vendor sources in this section were checked on 16 September 2026. These are documented capabilities; verify behaviour in a controlled pilot.

Log decisions, then test them

Routine events can include identity and application context, detector and policy versions, reason codes, tool and risk class, decision, payload size, content-part hash, transformation state and delivery outcome. Conversation logs create a concentrated sensitive-data store. Apply explicit access, encryption, region, retention and deletion rules to any raw-content exception.

Test direct and indirect injection, sensitive-data handling, cross-tenant retrieval, malformed output, tool misuse, exhaustion and control outages. Verify high-risk denials and approvals with deterministic oracles, then conduct impact-appropriate independent review or red teaming. Monitor false positives, missed detections, denials, latency, cost and drift.

The NIST Generative AI Profile calls for pre-deployment testing, regular adversarial evaluation, post-deployment monitoring and incident response.

Prepare incident response

Runbooks should cover injection, data exposure, compromised credentials, poisoned retrieval, abusive consumption and unauthorised tools. Teams need authority to disable models or tools, revoke credentials, quarantine sources and preserve content-minimised evidence.

Detect and triage, contain, assess exposure without copying sensitive content into unrestricted systems, recover and add a controlled regression case.

Prepare to learn from production

Detect

Alert on high-impact findings, errors and anomalous behaviour.

Contain

Bound the user, integration, feature or action without widening exposure.

Recover

Correct the failure and restore intended service safely.

Improve

Update runbooks, controls and regression tests with what was learned.

Monitoring is useful when it drives a rehearsed response and feeds durable improvements back into controls and tests.


The joint Guidelines for secure AI system development, co-sealed by ASD's ACSC, covers secure design, development, deployment, operation and maintenance.

Production checklist

  • Every path has an owner, identity, provider, data classification and tool inventory.
  • Input, retrieval, output and tool results retain provenance.
  • Sensitive input is minimised before provider delivery.
  • Output is validated before delivery or execution.
  • Tool authority is deterministic, least-privileged and model-independent.
  • Resource limits and exact-action approvals are enforced.
  • Routine telemetry excludes raw conversations.
  • Degraded and outage behaviour is explicit per path.
  • Tests run before launch and after material changes.
  • Claims distinguish protected, observed and unsupported paths.

Promptective's product overview explains this scope for supported AI traffic.

Authoritative LLM security sources

The original security guidance was reviewed on 21 August 2026. The vendor comparison was added and its sources checked on 16 September 2026. Recheck source versions and legal obligations before relying on a checklist.


Promptective applies policy and records content-minimised evidence on supported AI paths. Explore the protection model across browser, desktop and agent workflows.

Security review

Map policy to the AI paths your team uses.

See where Promptective can apply organisation policy and record content-minimised evidence.

Map your AI workflows

Website analytics are off.

LLM Security Best Practices | Promptective