보안 판단 프롬프트 파이프라인

여섯 단계 파이프라인

프롬프트는 즉석에서 만들어지지 않습니다. 여섯 단계를 거치며 요청 주변의 모든 사실을 수집·정리·검증한 뒤에야 LLM 에 전달됩니다. 각 단계는 독립된 패키지로 구현되어 있고, 이전 단계의 출력이 다음 단계의 입력이 됩니다.

Stage 1 · 수집

요청이 Spring Security 필터 체인(Filter Chain)에 들어오면 AuthBridge 구현체가 헤더·세션·속성 등 다양한 출처에서 주체를 추출합니다. 추출된 정보는 세 종류의 증거 도장(Stamp) 으로 포장됩니다. 이 세 도장이 이후 모든 단계의 원천 입력입니다.

증거 품질 여섯 등급

모든 증거가 같은 신뢰도를 가지지는 않습니다. 고객이 명시적으로 보낸 신호가 가장 강하고, 플랫폼이 구조적으로 관찰한 신호가 그 다음, 런타임 연속성으로 추정한 신호는 약합니다. BridgeSemanticBoundaryPolicy 는 모든 수집 시점에 다음 여섯 등급 중 하나를 붙입니다.

Stage 2 · 가공

수집된 증거만으로는 LLM 이 이 사람이 평소와 다르게 행동하는지 판단할 수 없습니다. 2 단계는 세 종류의 구성요소가 원시 증거를 관찰 가능한 패턴으로 확장합니다.

Stage 3 · 정제

프롬프트 주입(Prompt Injection) · 필드 스푸핑 · 신호 위조는 LLM 기반 보안 시스템이 가장 경계해야 할 위협입니다. CanonicalSecurityContextHardener 는 모든 필드를 LLM 에 넘기기 전에 필드별 정규화 절차를 거칩니다.

Stage 4 · 표준화

3 단계를 거친 모든 정보는 CanonicalSecurityContext 라는 단일 표준 컨텍스트 모델로 집약됩니다. 현재 구현은 Lombok 기반의 클래스이며, hardener가 필드 정규화와 기본값 보정을 수행한 뒤 프롬프트 조립 단계에 전달합니다. 22 개 필드와 7 개 프로필이 정해진 자리에 담기므로, 이후 프롬프트 조립 단계는 어떤 필드가 어디 있는지 예측 가능합니다.

CanonicalSecurityContext Java 클래스 구조

플랫폼 내부적으로 22개 기본 보안 필드와 7가지 행동 프로필을 단일 레코드로 담아 정규화하는 CanonicalSecurityContext의 실제 구조는 다음과 같습니다:

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class CanonicalSecurityContext {
    private Actor actor;                             // 주체 신원 (userId, tenantId, roleSet 등)
    private Session session;                         // 세션/인증 상태 (sessionId, clientIp, mfaVerified 등)
    private Device device;                           // 기기 핑거프린트 (os, browser 등)
    private Intent intent;                           // 행위 의도 분석 (botUserAgent, impossibleTravel 등)
    private Location location;                       // 지리/네트워크 위치 (country, city, ipBand, asn 등)
    private Resource resource;                       // 대상 리소스 정보 (resourceId, sensitivity, actionFamily 등)
    private Authorization authorization;             // 기존 인가 결과 (effectiveRoles, policyId 등)
    private Delegation delegation;                   // 대리 위임 증거 (delegated, agentId, allowedOperations 등)
    private ExecutionSubject executionSubject;
    private ExecutionEnvelope executionEnvelope;
    private Bridge bridge;                           // 브릿지 탐지/커버리지 정보
    private ObservedScope observedScope;             // 자율적으로 관찰된 범위 스냅샷
    
    // 7종 자율 행동/보안 프로필
    private SessionNarrativeProfile sessionNarrativeProfile;  // 세션 내 행동 시퀀스
    private WorkProfile workProfile;                          // 평소 개인 업무 프로필
    private RoleScopeProfile roleScopeProfile;                // 역할 범위 프로필
    private PeerCohortProfile peerCohortProfile;              // 동료 그룹(Cohort) 프로필
    private FrictionProfile frictionProfile;                  // 마찰 및 승인 이력 프로필
    private ReasoningMemoryProfile reasoningMemoryProfile;    // RAG/과거 사례 분석 메모리 프로필
    
    private ContextCoverageReport coverage;          // 정보 완성도 분석 보고서
    @Builder.Default
    private Map<String, Object> attributes = new LinkedHashMap<>();
    @Builder.Default
    private List<ContextTrustProfile> contextTrustProfiles = new ArrayList<>();
    @Builder.Default
    private Instant collectedAt = Instant.now();

    // 내부 정적 도메인 모델 클래스 예시
    @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;              // 대리 위임 목표 이탈 여부
    }
}

정보 완성도 네 단계

채워진 필드 수와 프로필 유무를 종합해 ContextCoverageEvaluator 가 완성도 등급을 매깁니다. 등급이 낮으면 LLM 에게 업무 패턴 기반 결론을 내리지 말라는 경고 문구가 자동 삽입됩니다.

Stage 5 · 조립

표준화된 컨텍스트는 이제 프롬프트가 됩니다. SecurityDecisionPromptSections 가 오케스트레이션하며, 2 개 시스템 섹션과 16 개 사용자 섹션(총 18 개 섹션 계획)을 렌더링합니다. 필드가 없으면 해당 빌더는 자기 섹션을 아예 출력하지 않습니다.

시스템 영역과 사용자 영역

18 개 섹션 계획

프롬프트 조립 시 각 섹션은 토큰 제약(Token Budget) 하에 아래 우선순위 등급에 따라 관리되며, 한도가 초과될 경우 P2 → P1 순서로 생략(Omit) 또는 요약(Compress)됩니다. 단, P0 등급 섹션은 절대 생략되거나 누락되지 않고 보존됩니다.

명시적 누락 지식

명시적 누락 지식(내부 섹션 키: EXPLICIT_MISSING_KNOWLEDGE)은 LLM 이 증거 공백을 확신으로 오해하지 않도록 만드는 P0 필수 품질 지표 섹션입니다. SecurityContextQualityUserSectionBuilder 가 PromptContextComposer.composeMissingKnowledgeSection() 을 호출해 만들며, 커버리지 공백이나 신뢰 프로필의 evidence caution 이 있을 때만 출력됩니다. 결핍 신호가 없으면 섹션을 비워 두며, 이는 누락이 아니라 “명시할 지식 공백 없음”을 의미합니다.

• 커버리지 공백 — missingCriticalFacts, remediationHints, confidenceWarnings 가 있으면 누락 지식 섹션을 생성합니다.
• 신뢰 한계 — ContextEvidenceLimitation, ContextTrustLimitation, ContextTrustWarning, ContextFieldCoverage, ContextFieldLimitation 을 별도 항목으로 노출합니다.
• 오탐 방지 — authorization effect 가 이미 해소된 경우 오래된 AUTHORIZATION_EFFECT 누락 경고는 출력하지 않습니다.
• Baseline 보강 — 개인/조직 baseline 이 희박하면 BaselineGapSupport 를 같은 섹션에 붙여 “증거 부족은 위험 또는 정상의 증거가 아니다”라는 제약을 전달합니다.
• 압축 보존 — compact budget 에서도 BaselineGapSupport, ConfidenceWarning, ContextEvidenceLimitation, ContextTrustLimitation, ContextTrustWarning 을 우선 보존합니다. 그래도 예산을 넘으면 요약/생략 내역을 compression ledger 에 남깁니다.

Stage 6 · 보정

LLM 이 응답을 돌려주면 끝이 아닙니다. 두 개의 안전장치가 순서대로 결과를 재조정합니다. 첫째는 자율성 제약, 둘째는 런타임 보정 입니다.

자율성 제약 (Autonomy Guardrail)

LLM 의 confidence 가 임계값 미만이거나 출력이 스키마를 벗어나면, PromptConfidenceGuardrail 이 최종 실행 액션을 더 안전한 상위 단계로 강제합니다. 제안 액션과 실행 액션이 분리 기록되어 감사 추적이 가능합니다.

런타임 보정 (Calibration)

제약이 적용되지 않은 결정은 SecurityDecisionCalibrationService 가 학습된 프로필로 미세 조정합니다. 과거 관찰 데이터에 근거해 신뢰도 가감과 액션 편향을 적용합니다.

• 시나리오 분류 — 현재 요청을 과거 유사 시나리오로 분류 (예: 낯선 위치 + 평소와 다른 리소스)
• 프로필 선택 — 최대 샘플 수와 운영자 검토가 완료된 프로필만 선택 (가장 강한 근거)
• 액션 편향 적용 — INCREASE_CHALLENGE · DECREASE_CHALLENGE · NONE 중 하나
• BLOCK 불변 보장 — BLOCK 액션은 어떤 편향으로도 변경 불가 (안전 원칙)
• 제약 우선 — 자율성 제약이 걸린 결정은 보정을 무시 (이중 개입 방지)

최종 결정 레코드

모든 단계를 통과한 뒤 만들어지는 SecurityDecision 은 단순히 ALLOW · BLOCK 한 값이 아닙니다. LLM 의 원시 판단, 정책 개입, 학습 보정이 모두 기록된 감사 가능한 레코드입니다.

SecurityDecision 결과 레코드 JSON 예시

보정과 자율성 제약을 모두 거친 후 최종 생성되는 SecurityDecision의 예시 데이터입니다. 자율성 제약이 걸려(autonomyConstraintApplied: true) 1차 LLM 제안인 ALLOW가 CHALLENGE로 승격된 모습을 보여줍니다.

{
  "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"
  }
}

사람과 Agent 의 프롬프트 차이

같은 파이프라인을 통과해도 주체 유형에 따라 프롬프트의 무게 중심이 달라집니다. 사람은 평소 행동 기준과의 편차가 핵심이고, Agent 는 허용된 목표 범위의 이탈이 핵심입니다.

관련 문서

LLM 공식검사

프롬프트 품질 보증 엔진은 프롬프트 문장만 검사하지 않습니다. 엔터프라이즈 공식검사는 프롬프트와 봉인된 증거 패키지로 생성된 LLM 판정이 보안 계약을 지키는지도 검증합니다.