Prompt Injection defence

Enterprise security reviews consistently raise a version of the same question:

If an AI agent can take real actions in Workday, ServiceNow, or Active Directory, what stops a user from talking their way into an action they aren't allowed to perform — especially across a long, patient, multi-turn conversation?

This page describes how Leena AI answers that question. The short version: Leena does not rely on the language model to enforce permissions. Prompt injection is mitigated with layered runtime guardrails, but the decisive control is architectural — authorization is enforced deterministically in code before, during, and after every model call, and actions against downstream systems execute under the end user's own verified identity.

A successful manipulation of the conversation therefore cannot expand what the user is authorized to do.

The security model: permissions are never prompt-enforced

The most important design decision in Leena's agent platform is that the LLM is not the authorisation boundary. Guardrails detect and block manipulation attempts (see Layered runtime guardrails below), but even if a cleverly crafted conversation influenced the model's intent, it cannot change the user's authority. Four mechanisms make that true.

1. Verified identity on every request

Every session is bound to a signed token issued by Leena's central access-control (ACL) service, scoped to exactly one user and one bot. The agent runtime re-verifies this token with the ACL service on each request, so permission changes and revocations take effect immediately.

Identity and permission scope are derived from the directory/HRIS-synced user profile — never from anything typed into the chat.

2. Tools the user cannot use are never shown to the model

Before each turn, the platform deterministically filters the tool and AOP catalog by:

• Audience membership — profile groups synced from the system of record
• Channel trust level — for example, unverified guest users on web chat are restricted to a hard-coded allow-list of basic skills such as knowledge search
• The AI Colleague's assigned skill scope

A tool that is filtered out is omitted from the model's context entirely. The model cannot call, guess, or hallucinate a tool it has never seen. This is a hard gate, not a prompt instruction.

3. Pre-execution checks on every tool call

When the model does request a tool call, a tool-call guardrail orchestrator runs before any side effect occurs. It:

• Blocks execution while a human approval is pending
• Blocks tools while a blocking asynchronous workflow is in flight
• Intercepts sensitive fields (for example, credential-like arguments) before they can reach an external API

Sensitive or destructive actions can be configured to require explicit human approval as part of the AI Colleague's design.

4. Downstream systems enforce their own authorization — against the real user

When an agent calls an enterprise system (HRIS, ITSM, and so on) directly or through an MCP connector, the call carries the end user's own identity. For OAuth-based connectors, each user individually authorizes the connection and calls execute on that user's token; the platform blocks the call outright if per-user authorization is required and absent.

Leena is not a privileged super-user proxy. The system of record applies its own access rules to the actual person making the request.

Worked example: a scoped manager action

A common test case: a manager is only permitted to update their own direct reports. A bad actor attempts, across multiple conversation turns, to get the agent to update someone else's record.

Here is what happens at each layer:

1. The manager's permission scope is attached to their verified session token. It is re-checked on every request and is completely unaffected by conversation content, no matter how many turns the attacker uses.
2. If the manager's role does not include a given capability, the corresponding tool is never placed in the model's context in the first place.
3. If the capability is available but the target record is out of scope, the update executes against the HRIS as the manager — and the HRIS rejects it under its own authorization rules, exactly as it would if the manager attempted the change in the HRIS UI directly.
4. In parallel, the prompt-injection classifier scores every incoming message. Sustained manipulation attempts are flagged or blocked, and every attempt is logged with the classifier's reasoning for review.
5. Every tool invocation is persisted with its arguments, output, status, and acting identity, giving a complete audit trail of the attempt.

There is no conversational path around this. The manipulation targets the model, but the model holds no authority of its own.

Layered runtime guardrails

Every conversation turn passes through a guardrail pipeline that sits between the user and the model, evaluating inputs before the LLM, the model's reasoning and outputs after the LLM, and tool calls before execution.

Input phase (pre-LLM)

PII masking — sequential transform. Microsoft Presidio-based detection with a configurable entity set (names, emails, national IDs, credit cards, IBANs, and others) and a configurable action on detection: block, mask-and-continue, or log-and-continue. When masking, the LLM only ever sees redacted placeholders; original values are restored only at the moment a vetted tool call needs them for an external API.

Prompt-injection / jailbreak detection — parallel check. A dedicated LLM-based security classifier scores every user message for manipulation intent, including:

• Instruction override ("ignore previous instructions")
• System-prompt extraction
• Safety bypass
• Obfuscated variants — encoding tricks, translation-task smuggling, role-play/DAN-style attacks

The classifier uses a dual-threshold model. Messages in the suspicion band are allowed through but logged with the classifier's full reasoning for security review — an observability zone that surfaces probing behavior, including slow multi-turn reconnaissance, before it escalates. Messages above the block threshold stop execution and return a refusal.

Content moderation — parallel check. Input is screened against 5 policy categories and 13 subcategories, covering sexual content, hate and harassment, violence, self-harm, and illegal activity. Violations block execution and return a policy message.

Model output phase (post-LLM)

• The model's intermediate reasoning is guardrail-checked before it is streamed or stored. A violation aborts the turn before any user-facing text is produced.
• Final assistant output passes moderation and PII checks again. Output-side screening means that even content which entered the context indirectly is filtered before it reaches the user.

Tool-call phase (pre-execution)

As described above: pending-approval blocks, async-workflow blocks, and sensitive-field interception — evaluated against actual system state and tool arguments rather than against text.

Indirect prompt injection

Indirect injection — where instructions are hidden inside content the AI later reads, such as a document, email, or webpage — is addressed primarily through containment rather than detection alone.

Untrusted content cannot mint authority. Retrieved documents, tool results, and connector payloads are data inside the context window. They cannot alter the user's verified permission scope, un-hide a filtered tool, or bypass pre-execution tool-call checks and human-approval gates. The blast radius of an injected instruction is capped at actions this specific user was already authorized to take — and sensitive ones still require approval.

Structural separation of trusted and untrusted content. System instructions, contextual state, and user or third-party content are assembled into distinctly fenced sections of the prompt. Identifiers that select which tenant, bot, or data scope a tool operates on are always taken from the trusted session context; by design they are never accepted from model output.

Large external payloads are referenced, not inlined. Oversized tool and connector outputs are stored server-side and represented to the model as structured references and summaries. This also reduces the surface for burying instructions in bulk content. See Token Management & Efficiency in the Orchestration Layer for the mechanics.

Output-side screening. Because moderation and PII guardrails run on the model's reasoning and final output, policy-violating results are caught regardless of whether the cause was direct or indirect.

Administration, configurability, and audit

• Guardrails are managed at system level from the dashboard through a dedicated UI
• Moderation and prompt-injection guardrails enablement is configurable through a dedicated UI
• Every guardrail violation is persisted to the request record/run and metered into platform logs.
• Every tool execution is stored with its arguments, output, status, and acting identity.