Security Decision Prompt Pipeline

Six-stage pipeline

A prompt is never built on the spot. Six stages collect, organise and verify every fact around the request before anything reaches the LLM. Each stage lives in its own package and the output of one stage is the input of the next.

Stage 1 · Collect

Once a request enters the Spring Security filter chain, an AuthBridge implementation pulls the principal out of headers, session attributes or request attributes. The extracted evidence is packaged into three kinds of evidence stamps. Those three stamps are the raw input for every later stage.

Six evidence quality tiers

Not all evidence carries the same weight. A signal the customer sent explicitly is the strongest; a platform-observed structural signal comes next; a fallback derived from runtime continuity is the weakest. BridgeSemanticBoundaryPolicy tags every collected field with one of the six tiers below.

Stage 2 · Process

Raw evidence alone is not enough for the LLM to decide whether a user is acting differently from usual. Stage 2 expands it through three families of components that turn primitive facts into observable patterns.

Stage 3 · Harden

Prompt injection, field spoofing and signal forgery are the top threats for any LLM-based security system. CanonicalSecurityContextHardener puts every field through field-specific normalisation before it ever reaches the model.

Stage 4 · Standardise

After stage 3, every piece of evidence is consolidated into a single standard context model — CanonicalSecurityContext. The current implementation is a Lombok-backed class; the hardener normalizes fields and fills required defaults before the compose stage receives it. Twenty-two fields and seven profiles sit in well-known places, so the compose stage always knows where each field lives.

CanonicalSecurityContext Java Structure

Below is the actual structure of CanonicalSecurityContext, which consolidates and normalizes 22 base security fields and 7 behavioral profiles into a single standard record:

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class CanonicalSecurityContext {
    private Actor actor;                             // Actor identity (userId, tenantId, roleSet, etc.)
    private Session session;                         // Session/Auth state (sessionId, clientIp, mfaVerified, etc.)
    private Device device;                           // Device fingerprint (os, browser, etc.)
    private Intent intent;                           // Behavioral intent analysis (botUserAgent, impossibleTravel, etc.)
    private Location location;                       // Geo/Network location (country, city, ipBand, asn, etc.)
    private Resource resource;                       // Target resource metadata (resourceId, sensitivity, actionFamily, etc.)
    private Authorization authorization;             // Pre-existing authorization outcome (effectiveRoles, policyId, etc.)
    private Delegation delegation;                   // Delegated authority evidence (delegated, agentId, allowedOperations, etc.)
    private ExecutionSubject executionSubject;
    private ExecutionEnvelope executionEnvelope;
    private Bridge bridge;                           // Bridge discovery & coverage details
    private ObservedScope observedScope;             // Observed behavior boundary snapshot
    
    // 7 behavioral/security profiles
    private SessionNarrativeProfile sessionNarrativeProfile;  // Session action narrative sequence
    private WorkProfile workProfile;                          // Individual work profile baseline
    private RoleScopeProfile roleScopeProfile;                // Role scope expectation profile
    private PeerCohortProfile peerCohortProfile;              // Peer cohort outlier profile
    private FrictionProfile frictionProfile;                  // Friction and approval lineage profile
    private ReasoningMemoryProfile reasoningMemoryProfile;    // RAG & reinforced reasoning memory profile
    
    private ContextCoverageReport coverage;          // Context coverage report
    @Builder.Default
    private Map<String, Object> attributes = new LinkedHashMap<>();
    @Builder.Default
    private List<ContextTrustProfile> contextTrustProfiles = new ArrayList<>();
    @Builder.Default
    private Instant collectedAt = Instant.now();

    // Nested static classes examples
    @Data public static class Actor {
        private String userId;
        private String organizationId;
        private String tenantId;
        private String principalType;
        private List<String> roleSet;
        private List<String> authoritySet;
    }

    @Data public static class Session {
        private String sessionId;
        private String clientIp;
        private String userAgent;
        private String authenticationType;
        private Boolean mfaVerified;
        private Integer concurrentSessions;
    }

    @Data public static class Delegation {
        private Boolean delegated;
        private String agentId;
        private String objectiveId;
        private List<String> allowedOperations;
        private List<String> allowedResources;
        private Boolean objectiveDrift;              // Delegation drift flag
    }
}

Four coverage levels

ContextCoverageEvaluator grades how complete the record is by counting filled fields and available profiles. A low grade automatically injects a warning into the prompt telling the LLM not to draw strong conclusions from "usual work patterns".

Stage 5 · Compose

The standardised context now becomes a prompt. SecurityDecisionPromptSections orchestrates the work and renders 2 system sections plus 16 user sections, for 18 section plans in total. When a field is missing, the builder for that section simply emits nothing.

System side and user side

18 section plans

During prompt composition, each section is governed by the priority tiers below under token limit constraints (Token Budget). If the token limit is exceeded, sections are omitted or compressed in order from P2 to P1. P0 sections are required and are never omitted.

EXPLICIT_MISSING_KNOWLEDGE

EXPLICIT_MISSING_KNOWLEDGE is a P0 required quality indicator section that prevents the LLM from mistaking evidence gaps for certainty. SecurityContextQualityUserSectionBuilder calls PromptContextComposer.composeMissingKnowledgeSection() and renders the section only when coverage gaps or trust-profile evidence cautions exist. If no gap signal exists, the section remains empty; that means there is no explicit missing knowledge to declare.

• Coverage gaps — missingCriticalFacts, remediationHints, or confidenceWarnings create the missing-knowledge section.
• Trust limits — ContextEvidenceLimitation, ContextTrustLimitation, ContextTrustWarning, ContextFieldCoverage, and ContextFieldLimitation are surfaced as explicit items.
• False-positive control — stale AUTHORIZATION_EFFECT missing-context warnings are suppressed once the authorization effect has been resolved.
• Baseline support — sparse personal or organisational baselines add BaselineGapSupport to remind the model that missing evidence is not proof of either risk or legitimacy.
• Compression preservation — compact budgets prioritise BaselineGapSupport, ConfidenceWarning, ContextEvidenceLimitation, ContextTrustLimitation, and ContextTrustWarning. If the budget still overflows, summarised or omitted details are recorded in the compression ledger.

Stage 6 · Calibrate

Getting a response back from the LLM is not the end. Two safety layers adjust the result in sequence: the autonomy guardrail and the runtime calibration.

Autonomy guardrail

If the LLM's confidence is below a threshold or the output deviates from the schema, PromptConfidenceGuardrail forces the final action up to a safer tier. The proposed action and the enforced action are stored separately to keep the audit trail intact.

Runtime calibration

Decisions the guardrail did not touch are fine-tuned by SecurityDecisionCalibrationService using learned profiles. Confidence adjustments and action biases are applied based on past observations.

• Scenario classification — group the current request with past similar scenarios (for example, unfamiliar location + unusual resource)
• Profile selection — pick only profiles that have enough samples and operator review
• Action bias — one of INCREASE_CHALLENGE · DECREASE_CHALLENGE · NONE
• BLOCK is immutable — a BLOCK decision is never changed by a bias (safety first)
• Guardrail wins — if the guardrail already intervened, calibration is skipped

The final decision record

What comes out the other end is the SecurityDecision. It is not just "ALLOW" or "BLOCK". It is an auditable record that carries the LLM's raw judgement, the policy intervention, and the learning calibration — all three.

SecurityDecision Result Record JSON Example

Below is an example of the finalized SecurityDecision JSON payload. In this scenario, the autonomy guardrail intervened (autonomyConstraintApplied: true) to escalate the primary LLM proposal from ALLOW to CHALLENGE due to low confidence:

{
  "eventId": "evt_8a9f3b2c1d",
  "action": "ALLOW",
  "autonomousAction": "CHALLENGE",
  "riskScore": 65.0,
  "confidence": 0.45,
  "llmAuditRiskScore": 65.0,
  "llmAuditConfidence": 0.45,
  "analysisTime": 1781572000000,
  "processingTimeMs": 342,
  "processingLayer": 1,
  "llmModel": "cortex-l1-interactive",
  "threatCategory": "ANOMALOUS_ACCESS",
  "reasoning": "User access from a new device (fingerprint mismatch) and unusual time of day, but baseline confidence is too low to completely block.",
  "mitigationActions": [
    "PROMPT_MFA_CHALLENGE"
  ],
  "requiresApproval": false,
  "autonomyConstraintApplied": true,
  "autonomyConstraintReasons": [
    "LOW_CONFIDENCE_ESCALATION"
  ],
  "autonomyConstraintSummary": "LLM confidence (0.45) is below the required threshold (0.60). Automatically escalated from ALLOW to CHALLENGE.",
  "technicalFallbackApplied": false,
  "sessionContext": {
    "sessionId": "sess_9283f12a",
    "clientIp": "192.0.2.1"
  }
}

How prompts differ for humans and agents

The pipeline is the same, but the centre of gravity shifts depending on who the subject is. For a human, the key axis is "deviation from the usual pattern". For an agent, it is "staying within the allowed objective".

Related documentation