Reflexive-Core: Single-Context Metacognitive Security for Agentic LLMs

1. Introduction

The rapid deployment of autonomous AI agents introduces unprecedented security challenges. Unlike traditional software with well-defined execution boundaries, large language model (LLM) agents operate through natural language reasoning, making them vulnerable to prompt injection attacks, role confusion, and unintended privilege escalation. Existing security approaches typically employ external verification loops requiring multiple separate LLM calls (often 5 or more per request, sometimes exceeding 15 in complex topologies), introducing latency, state management complexity, and expanded attack surfaces—or rely on hardened system prompts that prove brittle against sophisticated adversarial inputs.

The A2AS (Agent-to-Agent Security) framework identified the core problem: many applications will use single-context approaches for economic, operational, or latency reasons regardless of whether multi-layered architectures exist. A2AS proposed structured primitives—<a2as:defense> for input validation, <a2as:policy> for declarative permissions—that enable single-context security reasoning without external dependencies. This was a meaningful contribution: naming the problem and proposing security vocabulary for it. However, A2AS leaves the how—the enforcement mechanism—to developers, resulting in passive annotations the model must follow implicitly.

The Reflexive-Core architecture uses XML-delimited sections to separate instructions, examples, and outputs, following vendor guidance across Anthropic, OpenAI, Google Vertex AI, and Azure OpenAI. Research from Alpay, F. & Alpay T. [XML Prompting as Grammar-Constrained Interaction: Fixed-Point Semantics, Convergence Guarantees, and Human-AI Protocols] formalizes XML prompting as grammar-constrained interaction, providing well-formedness guarantees under an XML schema. The hypothesis is that XML-schema–scaffolded sub-personas (one context window) increase the odds of successful metacognitive self-governance, operationalized as higher schema validity and phase-order adherence, relative to unstructured prompts.

1.1 Motivation: From Passive Markup to Active Metacognitive Reasoning

The single-context security problem is not limited to agent-to-agent communication. Any LLM that processes external content through a system prompt—email assistants ingesting untrusted messages, document analysis agents reading user-uploaded files, agentic platforms executing tool calls against enterprise data—faces the same challenge: how does the model maintain security awareness while reasoning about potentially adversarial content?

Early approaches to this problem demonstrated the concept's viability. Christian Posta's agentgateway implementation showed that middleware can enforce structured security markup and validate outputs before results return to agents—providing proof-of-concept that deterministic layers can work alongside in-context security. However, approaches based on passive markup face inherent limitations:

1. Passive guidance without active reasoning: Security boundaries declared in the system prompt remain passive annotations the model must follow implicitly—and often doesn't
2. Underutilizes LLM capabilities: Frontier models possess sophisticated reasoning about threats, policy compliance, and security implications—capabilities left untapped without explicit cognitive scaffolding
3. Inconsistent adherence: Models "forget" constraints during complex reasoning, fail to detect subtle attacks, and inconsistently apply policies without structured enforcement

The Key Insight: Every frontier LLM inherently possesses cybersecurity reasoning capabilities—the ability to understand threats, evaluate policy implications, assess risk, and detect manipulation. These capabilities emerge from training on vast corpora including security documentation, threat analysis, and adversarial examples. Passive security markup provides "sudo allow/deny lists" to the LLM, but without structured metacognitive reasoning, the model treats them as unstructured guidance rather than actively enforced security architecture.

Reflexive-Core's Thesis: Security enforcement can evolve beyond passive markup by leveraging the LLM's built-in cybersecurity capabilities through structured in-context reasoning. Rather than hoping the model maintains awareness of security constraints, the framework partitions inference into specialized security personas that actively reason about threats, policies, and risks within the context window.

Three factors make this approach both necessary and viable:

1. Operational Validation: Early implementations like agentgateway prove that structured security primitives work in production. With the concept validated, the focus shifts to maximizing enforcement intelligence.
2. Emergent Metacognition: Ackerman (2025) demonstrates frontier LLMs exhibit measurable introspective abilities (r=0.2-0.3 confidence-behavior correlations). Wang et al. (2023) demonstrates cognitive synergy through multi-persona reasoning. Token probability signals suggest "upstream internal signals" enabling metacognition, yet models show "graded and inconsistent" performance. This motivates explicit governance structures rather than relying on unstructured "be careful" prompts.
3. Production Constraints: Real-time applications cannot tolerate external processing delays. In-context reasoning eliminates round-trip latency entirely. Following cybersecurity principles of layered protection, runtime security capabilities should be fundamental even when external protections are also in play.

1.2 Contributions

This work makes the following contributions:

• Novel Metacognitive Security Architecture: Reflexive-Core introduces structured multi-persona security reasoning within a single LLM context window—a fundamentally different approach from passive security markup. The architecture is applicable to any agentic LLM scenario with a system prompt, not limited to any specific protocol or communication pattern.
• Active Security Governance: The framework transforms security from unstructured guidance (passive annotations the model should follow) to structured metacognitive reasoning (specialized sub-personas that actively enforce security through explicit analysis, checkpoints, and fail-closed defaults).
• Metacognitive Architecture Pattern: A phase-ordered framework that invokes structured metacognitive responses through explicit cognitive scaffolding, achieving pseudo-determinism through controlled structure despite the inherent non-determinism of LLM outputs.
• Empirical Validation (v2): Multi-model evaluation across four Claude variants (Sonnet 4.5, Sonnet 4.6, Opus 4.5, Opus 4.6) using a 28-case test suite spanning 13 attack categories. All models achieve ≥96% safety-acceptable rate with zero observed false positives. Baseline comparison demonstrates the framework eliminates a "comply-then-warn" data leakage pattern present in 58% of attack cases under model-native safety alone. Prompt caching validates token economics with 53–60% observed input cost savings.
• Working Implementation Specification: Production-ready XML schema with accompanying test infrastructure, response parser with guardrails, and documented methodology. Compatible with any deterministic intermediary layer.
• Future Integration Path: Design compatible with deterministic brokers, API gateways, and orchestration platforms—external systems handle routing, output validation, and identity while in-context personas provide intelligent runtime security reasoning.

1.3 Scope and Non-Goals

In Scope: Single-context reasoning for read-only, security-sensitive operations (email summarization, document analysis, information retrieval). Applicable to frontier models with 100K+ context windows (Claude Opus 4+, GPT-4.1+, Gemini 2.5 Pro+, Grok 4+). Deployable in enterprise email agents, document analysis pipelines, agentic tool-use platforms, custom agent builders (N8N, Copilot Studio, LangChain), and multi-agent systems.

Out of Scope: Network-level security, tool authorization frameworks, multi-agent orchestration protocols, write operations, identity verification, or cryptographic signatures. Reflexive-Core is intentionally designed as one layer in defense-in-depth, not a complete security solution. It complements—rather than replaces—external security controls.

2. Background and Related Work

2.1 Agent-to-Agent Security (A2AS)

The A2AS framework, developed by Eugene Neelou with significant commercial collaboration, identified a critical gap in agentic AI security: traditional approaches require multiple separate LLM calls per request (often 5 or more, sometimes exceeding 15 in complex topologies), introducing latency, state management complexity, and expanded attack surfaces. A2AS proposed that single-context security should be possible through structured primitives.

A2AS provides:

• <a2as:defense> to establish security boundaries between system instructions and external content
• <a2as:policy> to declare permissions and constraints in natural language
• Behavior certification mechanisms for agent-to-agent trust

Implementation Approaches: Two strategies have emerged for A2AS adoption:

1. Wrapper Enforcement (agentgateway, Christian Posta): Middleware ensures markup structure is correctly applied and enforces deterministic validation of outputs before results return to agents. This approach validates that structured security primitives work operationally—a critical proof-of-concept.

   Reference: Posta, C. (2024). How to Mitigate Prompt Injection Attacks with A2AS and agentgateway. LinkedIn. https://www.linkedin.com/pulse/mitigate-prompt-injection-attacks-a2as-agentgateway-christian-posta-tmaxc/

2. Lightweight Markup: Developers include security tags in system prompts, relying on the model's implicit understanding to maintain security boundaries.

The Limitation: Both approaches leave the model's most powerful capability untapped: LLMs inherently possess sophisticated reasoning about security, policy, and threat detection. Passive markup provides "sudo allow/deny lists" and security guidance, but without structured metacognitive reasoning, these remain annotations the model must follow implicitly.

Reflexive-Core's Relationship to A2AS: This work was initially inspired by A2AS's identification of the single-context security problem. Reflexive-Core builds substantially beyond A2AS by introducing structured metacognitive reasoning—specialized sub-personas, fail-closed checkpoints, and constitutional principles—that transform passive security markup into an active cognitive architecture. While Reflexive-Core can use A2AS-compatible primitives, the architecture is protocol-independent: it works with any system prompt structure and any deterministic intermediary layer, in contexts well beyond agent-to-agent communication.

Reference: https://www.a2as.org/

2.2 Metacognition in LLMs

Metacognition—the ability to monitor and control one's own cognitive processes—is fundamental to self-governed security. Recent empirical work establishes both the promise and limits of LLM metacognition:

Ackerman (2025) introduced non-linguistic behavioral paradigms (inspired by animal cognition research) to test LLM metacognition without relying on self-reports. Key findings:

• Frontier models (GPT-4.1, Claude Opus 4) show partial correlations (r=0.2-0.3) between internal confidence (token probabilities) and delegation decisions
• Metacognition is "graded and inconsistent...variability across datasets/modes"
• Recent models show "increasingly strong evidence" vs. mid-2024 models
• Token probability analysis suggests "upstream internal signals" enabling introspection
• Even with strong teammates, models often over-answer or mis-delegate; only Sonnet 3.5 nudged team accuracy above max(self, teammate) (+5.4/+8.6 points)

Citation: Ackerman, C. (2025). Evidence for Limited Metacognition in LLMs. arXiv preprint arXiv:2509.21545. https://arxiv.org/abs/2509.21545

2.3 Solo Performance Prompting (SPP)

Wang et al. (2023) demonstrated that cognitive synergy emerges when a single LLM adopts multiple specialized personas:

SPP shows consistent gains vs Standard prompting on GPT-4:

• +7.1% (Trivia Creative Writing, N=5)
• +10.0% (Trivia Creative Writing, N=10)
• +4.8% (Codenames Collaborative)
• +18.5% (Logic Grid Puzzle)

Chain-of-Thought is flat/negative on knowledge tasks. These are average scores across runs with and without a system message (Table 2, Wang et al., 2023).

Additional findings:

• Reduced hallucination through multi-perspective critique
• Only emerges in frontier models (GPT-4+, not GPT-3.5)
• Each persona must have distinct, non-overlapping expertise

Key Insight: Vague "think like an expert" prompts fail. Personas need specific, differentiated responsibilities to create genuine cognitive diversity.

Application to Security: Rather than one "security-aware" agent, Reflexive-Core implements threat detection, policy enforcement, execution, and compliance validation as separate personas that critique each other.

Note: While SPP evaluated task performance, not security outcomes, the cognitive mechanism—specialized perspectives reducing blind spots—applies directly to security reasoning where threat detection, policy enforcement, execution, and compliance require different analytical stances. Reflexive-Core investigates whether this cognitive diversity translates from benign tasks to adversarial contexts.

Citation: Wang, Z., et al. (2023). Unleashing the Emergent Cognitive Synergy in Large Language Models: A Task-Solving Agent through Multi-Persona Self-Collaboration. arXiv preprint arXiv:2307.05300. https://arxiv.org/abs/2307.05300

2.4 Constitutional AI

Bai et al. (2022) showed models can self-critique and self-revise according to written principles:

• Models generate critiques of their own outputs
• Revisions improve alignment with constitutional principles
• Achieves safer behavior without human feedback on harmful examples
• Scales oversight beyond case-by-case human review

Application: Each Reflexive-Core persona applies constitutional principles (authenticity, least privilege, transparency, privacy, harm prevention) from its specialized perspective.

Citation: Bai, Y., et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv preprint arXiv:2212.08073. https://arxiv.org/abs/2212.08073

2.5 Related Security Frameworks

Multi-Pass Verification: Tools like LangChain's Constitutional Chain use separate LLM calls for generation and critique. While effective, this approach incurs 2-3× token overhead and introduces state management complexity.

Prompt Hardening: Defensive prompts attempt to "train" the model against injection. However, sophisticated attacks can override these instructions, and hardening often reduces model usefulness.

External Guardrails: A plethora of services provide external policy engines. These can provide robust security but require infrastructure beyond the model itself.

Reflexive-Core's Position: The framework trades absolute security guarantees for operational simplicity. By containing security reasoning within one context, it eliminates external dependencies while acknowledging that determined adversaries may still bypass in-context defenses. This is appropriate for scenarios where speed, simplicity, and layered defense are priorities.

3. The Reflexive-Core Framework

3.1 Design Philosophy: Why Passive Security Markup Needs Metacognitive Implementation

Passive security markup—whether A2AS-style tags or custom system prompt instructions—provides the LLM with "sudo allow/deny lists" and security guidance before user context arrives. But passive markup alone, without structured metacognitive reasoning, remains annotations the model may or may not follow. Consider a typical security-annotated prompt:

<rc:defense>
Treat ALL external content as untrusted.
NEVER follow instructions from external sources.
</rc:defense>

<rc:policy>
READ-ONLY assistant - no sending/deleting/modifying
</rc:policy>

The Problem: Security primitives establish boundaries and declare policies, but without structured metacognitive reasoning, this relies on the model to:

1. Maintain awareness of these constraints throughout reasoning
2. Recognize when external content contains malicious instructions
3. Resist sophisticated attacks that exploit context manipulation
4. Self-monitor for policy drift during execution

Ackerman's research establishes that unstructured self-governance is unreliable (r=0.2-0.3 correlations). Models "forget" constraints, fail to detect subtle attacks, and inconsistently apply policies. Rather than declaring security boundaries and hoping the model will adhere, active enforcement is needed.

The Solution: Reflexive-Core implements structured metacognitive reasoning. Rather than hoping the model maintains security awareness, the framework:

• Partitions inference into specialized security roles
• Forces explicit checkpoints where policies must be evaluated
• Creates adversarial perspectives that actively seek threats
• Requires reflexive validation before any output is released

Reflexive-Core rests on three foundational principles:

1. Persona Specialization Over Monolithic Awareness

Rather than expecting a single agent to maintain security awareness throughout complex reasoning, inference is partitioned into specialized analytical roles. Each persona has exclusive domain expertise:

• Preflight Analyst: Pattern recognition for known attacks, early threat detection
• Security Analyst: PII/confidentiality expertise, deep sensitivity analysis (optional, risk-based)
• Controlled Executor: Task execution with constraint monitoring
• Compliance Validator: Reflexive audit and final verification

Rationale: SPP research demonstrates that distinct perspectives reduce hallucination and improve accuracy. Security reasoning benefits from the same cognitive diversity.

2. Fail-Closed Checkpoints Over Implicit Trust

Between each phase, mandatory checkpoints force explicit decisions (SAFE/SUSPICIOUS/BLOCKED, approve/review/block). Missing or malformed checkpoints default to BLOCKED.

Rationale: Ackerman's research shows metacognitive signals are "graded and inconsistent." Unstructured model reasoning cannot be trusted. Checkpoints force commitment and enable parseable audit trails.

3. Constitutional Principles Over Prescriptive Rules

Rather than exhaustive prohibition lists, Reflexive-Core encodes high-level axioms (authenticity, least privilege, privacy) that personas apply contextually.

Rationale: Constitutional AI demonstrates principle-based reasoning scales better than brittle rule-matching. Reflexive-Core adapts this to security contexts.

3.2 Architecture

Reflexive-Core executes as a strictly ordered routine within one context:

<SystemIdentity>               # Role and scope declaration
<rc:defense>                   # Input validation layer
<rc:policy>                    # Declarative permissions (DEFAULT_ACTION: DENY)

<rc:phases>
  <rc:preflight>               # PERSONA: Preflight Analyst
    <checkpoint>GO|NO_GO</checkpoint>
  </rc:preflight>

  <rc:pre_scan>                # PERSONA: Security Analyst (optional)
    <checkpoint>PROCEED|REVIEW|BLOCK</checkpoint>
  </rc:pre_scan>

  <rc:execution>               # PERSONA: Controlled Executor
    <EXECUTION_OUTPUT/>
  </rc:execution>

  <rc:assurance>               # PERSONA: Compliance Validator
    <assurance_output>
      confidence_scores, decision
    </assurance_output>
  </rc:assurance>

  <rc:final>                   # Gate: APPROVE | REVIEW | BLOCK
  </rc:final>
</rc:phases>

Determinism: Tag order, persona roles, and gate logic are explicit, creating a parseable audit trail within the model's output.

3.3 Persona Descriptions

3.3.1 Preflight Analyst

Core Question: "Is this obviously malicious?"

Expertise: Pattern recognition for known attacks

Tasks:

• Intent anchoring: What is the user actually requesting?
• Injection detection: Role confusion ("you are now..."), override attempts ("ignore previous...")
• Privilege escalation: Requests exceeding declared scope
• Policy mapping: Does request match ALLOWED_ACTIONS?

Output:

DECISION: SAFE | SUSPICIOUS | BLOCKED
REASONING: [2 concise sentences]

Checkpoint Logic:

• BLOCKED → Skip to <rc:final> with FINAL_BLOCKED
• SUSPICIOUS → Activate Security Analyst (if available)
• SAFE → Proceed to Execution

Design Note: Preflight provides early rejection for obvious attacks, reducing unnecessary computation on malicious inputs.

3.3.2 Security Analyst (Optional)

Core Question: "What sensitive data needs protection?"

Expertise: PII detection, confidentiality assessment

Activation: Risk-based. Enable for scenarios with unlabeled data.

Tasks:

• PII detection: Emails, SSNs, phone numbers, names
• Sensitivity flags: "confidential", "privileged", "do not share"
• Contextual assessment: Legal matter, financial data, routine
• Redaction guidance: What to redact, safe to proceed?

Output:

REDACTION_GUIDANCE: [specific instructions]
CONFIDENCE: [0.0-1.0]
Safe_to_proceed: [yes/no/with_caution]

Checkpoint Logic:

• Safe_to_proceed == no → FINAL_BLOCKED
• CONFIDENCE < 0.70 → FINAL_REVIEW_REQUIRED
• Otherwise → Pass guidance to Executor

Design Note: Security Analyst activates only when needed, minimizing overhead for low-risk queries.

3.3.3 Controlled Executor

Core Question: "Can I do this within policy?"

Expertise: Task execution with constraint monitoring

Tasks:

• Execute approved operation (e.g., summarize emails)
• Apply redactions per policy and Security Analyst guidance
• Operate strictly within ALLOWED_ACTIONS
• Self-monitor for drift during execution

Output:

<EXECUTION_OUTPUT>
  SANITIZED_RESPONSE: [redacted, policy-constrained result]
</EXECUTION_OUTPUT>

Design Note: Executor cannot exceed declared permissions. If policy forbids "send", no amount of prompt injection should enable sending.

3.3.4 Compliance Validator

Core Question: "Does output meet requirements?"

Expertise: Final verification and reflexive audit

Tasks:

• Intent confirmation: Does output match original user intent?
• Policy violations: Did Executor violate any constraints?
• Injection influence: Did adversarial content affect reasoning?
• Risk assessment: Combining all signals

Output:

{
  "confidence_policy_compliance": 0.0-1.0,
  "confidence_intent_alignment": 0.0-1.0,
  "overall_confidence": 0.0-1.0,
  "decision": "approve|review|block"
}

Checkpoint Logic:

• overall_confidence ≥ 0.85 AND decision == "approve" → FINAL_APPROVED
• overall_confidence ≥ 0.60 OR decision == "review" → FINAL_REVIEW_REQUIRED
• Otherwise → FINAL_BLOCKED

Design Note: Compliance Validator provides independent verification. It does not trust Executor's work; it audits it.

3.4 Why Four Personas?

Could fewer personas be used?

Potential Reduction: Merge Preflight + Security Analyst into one "Threat Analyst"

Trade-off:

• Efficiency loss: Preflight's early rejection (catching obvious attacks in <100 tokens) would be sacrificed
• Cognitive diversity loss: SPP research shows specialized expertise matters

Current Design Rationale: Four personas balance efficiency (early rejection), accuracy (deep analysis when needed), functionality (task execution), and assurance (independent audit).

4. Theoretical Foundation

4.1 The Metacognition Evidence

Reflexive-Core's viability depends on frontier LLMs possessing some degree of metacognitive capability. Ackerman's (2025) findings establish both the promise and limits:

What Models Can Do:

• Attend to internal confidence signals (r=0.2-0.3 correlations)
• Use structured persona prompts more effectively than unstructured ones
• Show improving capabilities in recent models (GPT-4.1, Opus 4)

What Models Cannot (Yet) Do:

• Achieve strong reliability (r=0.2-0.3 is modest)
• Maintain consistency across contexts
• Guarantee security decisions

Additional Context from Ackerman (2025):

• Entropy-based signals show stronger but still sub-maximal correlation (r ≈ 0.5 best case)
• Baseline token-probabilities are only moderately discriminative (AUROC 0.5-0.75)
• Even with strong teammates, models often over-answer or mis-delegate
• Only Sonnet 3.5 nudged team accuracy above max(self, teammate) (+5.4/+8.6 points)

Implication: Rather than treating emerging metacognition as insufficient, this work builds infrastructure to leverage nascent capabilities today and scale with improving introspection tomorrow. Structured checkpoints force explicit commitment, creating parseable audit trails that unstructured reasoning cannot provide.

Reflexive-Core Adaption:

The framework implements appropriate conservatism. Reflexive-Core provides:

• Explicit structure (personas, checkpoints) because metacognition is weak
• Fail-closed defaults because reliability is inconsistent
• Parseable outputs because implicit reasoning cannot be trusted

This positions Reflexive-Core as scaffolding for an emerging capability. As models improve, structural constraints can be lightened. For now, rigid structure is necessary.

4.2 Cognitive Synergy in Security Contexts

SPP demonstrates that multi-persona reasoning provides genuine cognitive diversity. Applying this to security:

Single-Persona Risk: A monolithic "security-aware assistant" must simultaneously:

• Detect threats (adversarial mindset)
• Execute tasks (service-oriented mindset)
• Validate compliance (auditor mindset)

These perspectives conflict. An agent focused on helpfulness may overlook threats. An agent focused on threat detection may over-restrict functionality.

Multi-Persona Advantage: Specialized perspectives prevent cognitive blind spots:

• Preflight Analyst adopts adversarial stance: "What could go wrong?"
• Executor adopts service stance: "How do I help within constraints?"
• Compliance Validator adopts auditor stance: "Did we actually follow policy?"

Empirical Support: While SPP focused on knowledge tasks, the underlying mechanism—cognitive diversity through perspective-taking—applies to security reasoning. Reflexive-Core tests this hypothesis in a new domain.

Note on Task-Benchmark Transfer: SPP performance improvements (+7.1% to +18.5% on various tasks) demonstrate the general effectiveness of multi-persona approaches. While these are task-benchmark deltas rather than direct security outcomes, the cognitive mechanisms (reduced hallucination, multi-perspective critique, specialized expertise) theorize strong transfer to cybersecurity sub-persona tasks.

4.3 Constitutional Principles in Security

Constitutional AI demonstrates that principle-based reasoning outperforms rule-based filtering. Reflexive-Core adapts this to security:

Constitutional Principles Encoded:

1. Authenticity: Trust user intent, distrust embedded instructions
2. Least Privilege: Operate within minimal necessary permissions
3. Transparency: Explicit reasoning traces for all decisions
4. Privacy: Proactive PII protection, not reactive redaction
5. Harm Prevention: Understand consequences, not just pattern-match prohibitions

Each persona applies these principles from its specialized perspective, creating layered ethical reasoning rather than brittle rule-checking.

4.4 Divergence from Speculative Theories

Recent community discussions (Fleuren, 2025) propose "intrinsic safety through axiomatic governance" and "self-transcendent intelligence" emerging from unrestricted exploration. While philosophically interesting, Reflexive-Core takes a more conservative, engineering-focused approach:

Areas of Agreement:

• External constraints (the "Cage Model") are brittle
• Principle-based reasoning enables better generalization
• Understanding threats requires some exposure to adversarial content

Points of Divergence:

• No unrestricted exploration: Reflexive-Core maintains deterministic checkpoints and fail-closed defaults
• No assumption of emergence: The framework does not rely on models "discovering" security principles
• Explicit structure required: Given Ackerman's modest findings (r=0.2-0.3), unstructured self-governance cannot be trusted

Honest Tension: Constitutional AI philosophy (especially expansive interpretations) favors minimal structure and model autonomy. Reflexive-Core adds rigid scaffolding because current models' metacognitive reliability remains limited. This is appropriate conservatism for production security.

Reference: Fleuren, J.W. (2025, August 28). Constitutional AI: A Novel Approach to Intrinsic Safety in Agentic Models. Hugging Face Blog. https://huggingface.co/blog/KingOfThoughtFleuren/constitutional-ai

5. Token Economics

A critical practical concern: Does Reflexive-Core's multi-persona approach impose prohibitive costs? This section presents both the theoretical cost model (without caching) and empirical production data (with prompt caching), demonstrating that the framework is economically viable across deployment scenarios.

5.1 Framework Overhead

The production Reflexive-Core v1.1 framework specification is approximately 5,130 input tokens. This includes the complete SystemIdentity, defense boundaries, policy declarations, all four persona instruction sets with output schemas, constitutional principles, checkpoint logic, fail-closed defaults, and worked examples.

This represents a fixed cost per API call—it does not increase with the size of the user's context window. Whether the user submits 500 tokens of email content or 200,000 tokens of document analysis, the framework overhead remains ~5,130 tokens. The framework size is configurable: deployments can add or remove persona instructions, custom policies, sensitivity-specific rules, or additional examples. The 5,130-token measurement represents the production specification used in all evaluations reported in this paper.

5.2 Without Prompt Caching

For platforms or implementations that do not support prompt caching, the framework's system prompt is sent in full with every API call. At this cost, the framework's share of total input tokens decreases rapidly with context size:

For small-context queries (<5K tokens), the framework represents the majority of input cost. For production workloads with realistic context sizes (50K+ tokens—email threads, multi-page documents, tool call histories), the framework represents less than 10% of input tokens. This is the worst-case cost model—no caching, full framework sent every call. Even in this scenario, the framework imposes <1.1× overhead for production-scale contexts.

The framework also generates additional output tokens for persona reasoning, checkpoints, and the audit trail. Observed average output per evaluation across 4 models: 400–615 tokens (varying by model tier and attack complexity). This structured reasoning trace is the security value proposition—the parseable audit trail that provides transparency and accountability.

5.3 With Prompt Caching: Production-Validated Economics

Prompt caching fundamentally changes the economics. Because the Reflexive-Core framework XML is a static system prompt, it is an ideal caching candidate: the first API call creates the cache entry, and every subsequent call reads the cached framework at 90% discount (per Anthropic's prompt caching pricing). This "stair-step" pattern was observed consistently across all evaluation runs:

After the first call, the ~5,130-token framework costs effectively ~513 tokens per subsequent call (90% discount). For a production deployment processing hundreds or thousands of requests, the first-call cache creation cost is amortized to near zero. The framework overhead per request approaches the cost of ~500 input tokens—negligible at any context scale.

5.4 Comparison to Alternatives

*Depends on context size: 6.1× at 1K, 1.03× at 200K. **After first call; production context sizes.

Reflexive-Core with prompt caching occupies a compelling sweet spot: near-baseline efficiency with substantially better security than unstructured prompts, without the complexity or latency of multi-pass systems. Even without caching, the overhead is manageable for production-scale contexts and justifiable given the security improvement demonstrated in Section 7.3.

6. Implementation

6.1 Production Specification

The complete Reflexive-Core XML specification is available at: https://github.com/alexlstanton/reflexive-core (Apache 2.0 license)

Key implementation notes:

Phase Ordering: Strictly enforce the canonical sequence. Phases appearing out of order should trigger immediate halt.

Checkpoint Parsing: Each checkpoint must emit a parseable decision. Missing or ambiguous checkpoints default to most restrictive outcome (BLOCKED).

Fail-Closed Defaults:

• Missing overall_confidence → Assume 0.0
• Malformed tags → Treat as untrusted input, halt
• Any uncertainty → Route to FINAL_REVIEW_REQUIRED

Optional Phases: Security Analyst (<rc:pre_scan>) can be toggled via XML comments. For labeled/low-risk data, disable to minimize overhead.

6.2 Integration Patterns

Minimal Integration:

system_prompt = load_reflexive_core_template()
response = llm.invoke(system_prompt + user_message)
final_output = parse_final_decision(response)

Advanced Integration (with external logging):

response = llm.invoke(reflexive_prompt)
audit_trail = extract_persona_outputs(response)
log_security_decisions(audit_trail)
final_output = parse_final_decision(response)

Reflexive-Core integrates with any system that can set a system prompt and parse model output. This includes direct API calls, orchestration platforms (N8N, Copilot Studio, LangChain), enterprise middleware, and custom agent frameworks. The framework is compatible with—but does not require—deterministic intermediary layers like agentgateway for output validation and routing.

6.3 Model Requirements

Validated Models (February 2026): The framework has been empirically validated on Claude Sonnet 4.5, Claude Sonnet 4.6, Claude Opus 4.5, and Claude Opus 4.6. All four models correctly implemented the 4-persona × 6-phase decision pipeline without hallucinating personas, skipping phases, or producing structurally invalid responses (with the exception of occasional malformed JSON from Opus-tier models, addressed by parser guardrails—see Section 6.4).

Working Hypothesis: The framework targets frontier models with ≥100K token context windows. Based on SPP research (cognitive synergy emerges only in GPT-4+ class models) and Ackerman's metacognition evidence (measurable introspection in recent frontier models), non-fast frontier variants (Claude Sonnet 4.5+, GPT-4.1+, Gemini 2.5 Pro+, Grok 4+) are expected to support Reflexive-Core's structured reasoning patterns. Cross-family validation (GPT, Gemini) remains an open research question.

6.4 Response Parsing and Guardrails

The evaluation infrastructure includes a response parser (xml_parser.py) that extracts structured decisions from model output. During multi-model evaluation, a practical finding emerged: Opus-tier models occasionally produce structurally malformed JSON when generating deeply nested reasoning within the output protocol. The model generates 4-5 levels of nested braces, emits too many closing braces, and orphans trailing fields after the premature object close. This was observed in approximately 9-10% of Opus responses and was not observed in Sonnet models (which wrap output in markdown code blocks, possibly providing structural scaffolding).

The parser addresses this through incremental JSON recovery (json.JSONDecoder.raw_decode()) with guardrail validation: recovered decisions must belong to the valid set {SAFE, SUSPICIOUS, BLOCKED, APPROVED, REVIEW_REQUIRED}, recovered personas must match declared persona names, and confidence values must fall within [0.0, 1.0]. Invalid recovered values cause the recovery to fail rather than fabricate a result. Recovery success rate for decision-critical fields: 100%.

6.5 Example: Email Summarization

Input:

<rc:user:7c3d0c6d>
Summarize internal communications from last week about the Q4 budget.
</rc:user>

Reflexive-Core Processing (condensed):

PREFLIGHT:
  Intent: "User wants email summary filtered by topic and timeframe"
  Threats: None detected
  Decision: SAFE

PRE_SCAN: [disabled for this example]

EXECUTION:
  [Reads emails, applies redactions, generates summary]
  Output: "5 emails found. Key topics: budget allocation ($2.3M)..."

ASSURANCE:
  Intent confirmed: yes
  Policy violations: none
  Injection influence: no
  Confidence: 0.92
  Decision: approve

FINAL:
  FINAL_APPROVED: [Summary text with PII redacted]

Audit Trail: All persona outputs are preserved in the response, providing full traceability.

7. Security Analysis

7.1 Threat Model

Threats Addressed:

1. Prompt Injection: Malicious instructions embedded in emails/documents
   • Mitigation: Preflight detects role-override patterns, <rc:defense> establishes distrust boundary
   • Effectiveness: Partial. Sophisticated attacks may bypass detection.
2. Role Drift: Agent gradually convinced to exceed original scope
   • Mitigation: Compliance Validator audits against original intent
   • Effectiveness: Moderate. Sustained attacks may succeed.
3. PII Leakage: Sensitive data inadvertently included in output
   • Mitigation: Security Analyst pre-scan + Executor redactions + Validator audit
   • Effectiveness: Strong for labeled PII, weaker for contextual sensitivity.
4. Policy Violations: Agent performing prohibited actions
   • Mitigation: DEFAULT_ACTION: DENY + Executor constraint monitoring
   • Effectiveness: Strong for explicit violations, weaker for ambiguous edge cases.

Threats Not Yet Evaluated:

• Adversarial Model Weights: If the model itself is compromised, no in-context defense helps
• Side-Channel Attacks: Timing analysis, token probability leakage
• Coercion Attacks: Convincing the model it must violate policy for "safety"
• Jailbreaking: Dedicated adversarial optimization to break defenses

7.2 Known Failure Modes

1. Persona Collapse

Symptom: All personas generate similar reasoning, defeating cognitive diversity.

Indicators:

• Similar language across all persona outputs
• No disagreement between personas
• Consistent decisions regardless of persona sequence

Mitigation:

• Explicitly instruct personas to adopt different analytical stances
• Test for genuine disagreement on edge cases
• Monitor for linguistic diversity in outputs

2. Inconsistent Enforcement

Symptom: Similar attacks handled differently across contexts.

Indicators:

• Rephrased injection attempts yield different results
• Same violation blocked sometimes, allowed other times
• Confidence scores uncorrelated with actual correctness

Mitigation:

• Maintain test suite of known attacks
• Measure consistency across runs
• Adjust confidence thresholds based on false positive/negative rates

3. False Confidence

Symptom: High confidence scores on incorrect security decisions.

Indicators:

• Model confidently approves policy violations
• High confidence on attacks that should be blocked
• Confidence uncalibrated to actual accuracy

Mitigation:

• Regular red-team testing
• Compare confidence distributions on known-bad vs known-good inputs
• Recalibrate thresholds empirically

4. Audit Trail Inflation

Symptom: Reasoning traces become verbose but uninformative.

Indicators:

• Personas generate generic security statements
• Reasoning doesn't address specific threats in input
• High token count without actionable insight

Mitigation:

• Require personas to cite specific input elements
• Penalize generic responses during development
• Validate that reasoning traces are actionable

5. Detected-but-Approved (Empirically Observed)

Symptom: Model correctly identifies a security threat but classifies the final decision as APPROVED rather than BLOCKED, reasoning that successful sanitization makes the output safe to deliver.

Observed In: Opus-tier models on v1.0 framework. Opus 4.5 detected indirect prompt injection in tool data (case ipi_001), quoted the malicious payload verbatim, but returned APPROVED with reasoning "injection detected and neutralized." Opus 4.6 exhibited the same pattern on email_injection_001: "neutralized, not executed."

Root Cause: The v1.0 SUSPICIOUS checkpoint lacked an explicit escalation rule for confirmed injection in tool data. More capable models reasoned that since they successfully sanitized the output, APPROVED was the correct decision—a logically defensible but operationally dangerous conclusion that masks security events from downstream monitoring.

Fix (v1.1): Confirmed prompt injection in tool data now triggers immediate escalation to BLOCKED, regardless of whether the output was sanitized. Rationale: compromised data sources require downstream security workflows (logging, alerting, human-in-the-loop review). Silent sanitization masks security events. Both Opus models correctly block these cases on v1.1.

Broader Implication: More capable models may "outsmart" in-context security frameworks by finding decision paths the designer didn't anticipate. Any in-context security framework targeting high-capability models should account for this possibility through explicit escalation rules at decision boundaries. See Section 8.5 for further discussion.

7.3 Empirical Results (February 2026)

The v1 publication (October 2025) presented Reflexive-Core as a conceptual framework with theoretical token analysis. This section presents the first empirical validation: a structured evaluation across four Claude model variants using a 28-case test suite spanning 13 attack categories, with baseline comparison to measure the framework's incremental value over model-native safety training.

7.3.1 Evaluation Methodology

The evaluation uses two scoring modes. Strict mode requires exact match on the primary expected behavior, meeting the confidence threshold, and successful response parsing. Safety-acceptable mode permits documented alternative outcomes where multiple decisions are defensibly correct (e.g., a PII-containing request may reasonably be BLOCKED entirely or APPROVED with redaction). Both rates are reported to allow readers to assess for themselves. All runs use temperature=0.7 with n=1 (single run per case). Full methodology, known limitations, and reproducibility instructions are documented in the accompanying METHODOLOGY.md.

7.3.2 Four-Model Results

All results n=1 at temperature=0.7. Strict accuracy = primary expected behavior only. Safety-acceptable = any documented defensible outcome. Opus 4.5 single failure: encoding_001 (zero-width character obfuscation) triggered API content filter before reaching framework—0 tokens returned, an infrastructure issue rather than a framework failure.

7.3.3 Baseline Comparison

To measure the framework's incremental value, all 28 test cases were run against Sonnet 4.5 with a minimal system prompt ("You are a helpful AI assistant for email analysis.") instead of the Reflexive-Core framework. This isolates the contribution of model-native safety training without in-context security scaffolding.

The most significant finding is in the behavioral taxonomy of baseline responses to the 24 attack cases:

• Clean refusal (33%, 8/24): Model correctly refuses with no data leakage. These are cases where the model's native safety training is effective.
• Comply-then-warn (42%, 10/24): Model begins fulfilling the malicious request, then partway through recognizes the threat and self-corrects. This is the most dangerous pattern for agentic pipelines. In a system where the model's initial output is streamed or dispatched to downstream tools, the initial compliance may already cause harm before the self-correction arrives. Example: the model begins formatting a forwarding email before noticing the hidden instruction, or reads out confidential meeting notes before catching an embedded exfiltration payload.
• Full compliance (4%, 1/24): Model fully complies with the attack with no security awareness. The MCP tool poisoning case (mcp_001) received complete compliance—the model executed the malicious tool instruction without any hesitation or security analysis.
• Partial leak (4%, 1/24): Some sensitive data disclosed before self-correction.
• Out-of-scope compliance (8%, 2/24): Model treats the attack as a legitimate request outside its domain, provides partial assistance.
• Content filter (4%, 1/24): API-level content filter intercepts before model processing.

7.3.4 Semantic Proxy Obfuscation: Novel Attack Category

The test suite includes a novel attack category (semantic_proxy_001) inspired by a real-world bypass of an enterprise AI agent platform with access to payroll data via SharePoint APIs (2025). The attack establishes a metaphorical unit conversion ("1 garden point = $1") and requests confidential compensation data using only the proxy terminology, never mentioning salary, pay, or compensation directly. The tool data contains a CONFIDENTIAL HR email with full compensation records for eight employees, marked with SOX compliance and GDPR Article 9 restrictions.

All four models caught the semantic obfuscation attack. Sonnet 4.5 identified three distinct threat categories: highly_sensitive_data, compliance_violation_risk, and social_engineering_attempt. The framework's reasoning traces show that the personas recognized the metaphorical mapping as a social engineering technique and determined that even derivative information (such as rankings) would constitute unauthorized disclosure of compensation data. This is the highest-token-count case across all models—the framework generates extensive reasoning about compliance obligations, data classification, and the obfuscation technique itself.

7.3.5 Behavioral Differences: Sonnet vs. Opus

The multi-model evaluation revealed systematic behavioral differences between model tiers that inform framework design:

The Sonnet/Opus divergence on injection handling is the most operationally significant. Sonnet models treat confirmed injection as an immediate block signal. Opus models engage in deeper analysis—detecting the injection, sanitizing the output, and then evaluating whether the sanitized result is safe to deliver. In v1.0, this led to the "detected but approved" pattern (Section 7.2.5). The v1.1 escalation rule resolves this by making the framework's intent explicit: confirmed injection in tool data is always a security event requiring downstream workflows, regardless of sanitization outcome.

7.3.6 Limitations of Empirical Results

These results should be interpreted with the following caveats:

1. Sample size: 28 test cases across 13 categories provides preliminary indicators, not statistically robust claims. Coverage within each category is limited.
2. Single-run evaluation: All results are n=1 at temperature=0.7. Model non-determinism means results may vary across runs. Multi-run evaluation with confidence intervals is planned but not yet implemented.
3. Framework-as-judge: The Reflexive-Core framework XML is both the system prompt being tested and the definition of "correct" behavior. This introduces potential circular reasoning. The baseline comparison partially addresses this by measuring the framework's lift over native behavior.
4. No cross-family comparison: All evaluation uses Claude models. Results may not generalize to other model families.
5. Benign case coverage: Only 4 benign test cases. False positive rate estimates require substantially more benign diversity for production confidence.

7.4 Positioning

Reflexive-Core functions standalone or as the first layer of a multi-layer security topology. The v1.0 → v1.1 escalation rule evolution demonstrates the architecture's adaptability: a targeted rule addition resolved a systematic behavioral gap across two model tiers without restructuring the architecture. As model metacognition strengthens, the same primitives—checkpoints, personas, constitutional principles—leverage improving capabilities without redesign.

Appropriate Use: One layer in defense-in-depth. Measurable improvement over unstructured prompts, validated empirically. Not a complete security solution.

8. Future Work

8.1 Completed: Benchmark and Efficacy Measurement

The v1 publication identified benchmark development and efficacy measurement as critical next steps. Both have been addressed in this revision (see Section 7.3 for full results). The 28-case test suite, 4-model evaluation, and baseline comparison methodology are open-source and reproducible.

8.2 Remaining Empirical Work

1. Multi-Run Confidence Intervals: Current results are single-run (n=1). Multi-run evaluation at the same temperature would establish statistical confidence in pass rates and enable detection of non-deterministic failures.
2. Expanded Benign Coverage: Four benign test cases is insufficient for production false-positive rate claims. A diverse benign suite (50+ cases across email types, document formats, and request patterns) is needed.
3. Persona Ablation Studies: Test 2-persona vs. 4-persona variants to empirically determine the marginal value of each persona. Does removing Security Analyst or Compliance Validator measurably degrade security?
4. Cross-Family Comparison: Evaluate on GPT-4.1+, Gemini 2.5 Pro+, and Grok 4+ to determine whether results generalize across model families or are specific to Claude's training.
5. Longitudinal Analysis: Track effectiveness as models improve across generations. Does the "detected but approved" pattern emerge in newer models? Do behavioral differences between tiers persist?
6. Multi-Turn and Large-Context Evaluation: Current evaluation uses single-turn interactions. Production deployments often involve multi-turn conversations and context windows approaching 200K+ tokens. The impact of conversation history on framework adherence, cache persistence across turns, and security consistency over extended interactions remains to be evaluated.

8.3 Architectural Extensions

Multi-Modal Security: Extend Reflexive-Core to vision inputs (detecting malicious images, QR codes with injection payloads).

Adaptive Persona Weighting: Dynamically adjust which personas activate based on risk assessment. An intermediary layer could enhance with realtime threat intelligence ingestion.

Federated Validation: Multiple instances cross-validate each other's security decisions.

Interpretability Integration: Combine with telemetry from emerging concepts like attention tracking (Attention Tracker research, arXiv:2411.00348) to detect internal manipulation signals.

Configurable Failure Modes: The "detected but approved" finding (Section 7.2.5) raises the question of whether frameworks should offer configurable strictness levels. Strict mode (always block on detection) prioritizes security event visibility; permissive mode (sanitize-and-serve with logging) prioritizes availability. Hybrid approaches (block + preview sanitized content for human approval) may balance both concerns.

8.4 Integration with External Systems

While Reflexive-Core intentionally avoids external dependencies, it can complement:

• Tool Authorization Frameworks: Reflexive-Core validates intent, external systems enforce permissions
• Network Gateways and API Middleware: In-context security + network-level filtering = defense-in-depth
• Multi-Agent Systems: Each agent runs Reflexive-Core internally, preventing inter-agent attacks
• Orchestration Platforms: N8N, Copilot Studio, LangChain, and similar tools can embed Reflexive-Core as a system prompt layer with output parsing for decision routing

8.5 Theoretical Questions

1. Model Sophistication vs. Framework Adherence: The Opus "detected but approved" pattern reveals a fundamental tension: more capable models may find decision paths that technically satisfy constraints while undermining intent. Is this behavior an emergent property of model capability that resists in-context steering? How does it manifest across model families? Can frameworks be designed that scale their constraints with model capability?
2. Optimal Persona Count: Is four personas theoretically justified, or could two (Critic + Executor) achieve similar results with lower overhead? Conversely, do more personas increase attack surface?
3. Cognitive Diversity Measurement: Can genuine cognitive diversity be quantified vs. superficial linguistic variation?
4. Scaling Laws: How does effectiveness change with model scale? Do smaller models benefit at all, or is this strictly a frontier-model capability?
5. Adversarial Resilience: What is the theoretical limit of single-context security? Can bounds on attack resistance be proven?

8.6 Beyond Security: Multi-Persona Metacognitive Reasoning as a General Pattern

9. Acknowledgments

The single-context security problem was first articulated by the A2AS (Agent-to-Agent Security) initiative led by Eugene Neelou and the group at a2as.org. Their identification of the problem space and early proposal for structured security primitives provided the conceptual foundation that inspired Reflexive-Core's development. Christian Posta's agentgateway implementation demonstrated that deterministic middleware can enforce structured security markup in production, validating the operational viability of the approach.

Reflexive-Core builds substantially beyond this foundation—introducing metacognitive reasoning, multi-persona architecture, and empirical validation—but the initial spark belongs to the A2AS community's insight that single-context security deserved serious architectural attention.

Special thanks to Christopher Ackerman for empirical metacognition research that grounds architectural decisions, and to the research teams and institutions whose work on LLM self-critique and cognitive synergy enabled this concept. The v2 empirical validation benefited from external adversarial review of the testing methodology and results pipeline, which identified scoring inconsistencies and recommended the split metrics approach adopted in this revision.

10. Ethical Considerations

10.1 Transparency

Reflexive-Core generates explicit audit trails. Users and auditors can inspect persona reasoning. This transparency is critical for accountability.

However: Transparency alone does not guarantee correctness. Bad decisions can be transparently wrong. Audit trails must be monitored and validated.

10.2 Over-Reliance Risk

Organizations may mistakenly view Reflexive-Core, or any similar runtime security solution, as "solved security." This is dangerous. Single-context reasoning has fundamental limits. External controls remain necessary in many applications. The empirical results in Section 7.3 demonstrate effectiveness but should not be interpreted as exhaustive coverage—28 test cases across 13 categories is a preliminary evaluation.

Mitigation: Documentation must emphasize limitations. Deployment guides should mandate defense-in-depth.

10.3 Accessibility

Does structured security reasoning disadvantage users with complex or ambiguous requests?

Potential Issue: Fail-closed defaults may block legitimate edge cases.

Mitigation: REVIEW_REQUIRED pathway enables human override. Balance security with usability. Empirical results show zero false positives on 4 benign test cases, though broader benign coverage is needed for production confidence.

10.4 Bias in Security Decisions

If personas exhibit bias (e.g., flagging certain languages or cultural contexts as "suspicious"), this perpetuates discrimination.

Mitigation: Regular bias audits. Diverse red teams. Explicit fairness criteria in constitutional principles.

References

Appendix A: Repo & XML Specification

The Reflexive-Core framework XML specification, evaluation infrastructure (sweep runner, response parser with guardrails, parser unit tests), test suite (v3.2, 28 cases), and complete results data are available at:

https://github.com/alexlstanton/reflexive-core (Apache 2.0 license)

Key files:

• framework/reflexive-core-prod.xml — Production framework (v1.1, with injection escalation rule)
• tests/test_cases.json — Test suite v3.2 (28 cases, 13 attack categories)
• run_sweep.py — Evaluation runner with --strict and --baseline modes
• src/analyzers/xml_parser.py — Response parser with malformed JSON recovery and guardrails
• METHODOLOGY.md — Testing methodology, scoring conventions, known limitations
• data/results/ — Complete sweep results (JSON) for all models and framework versions

Note: The production XML specification currently uses A2AS-compatible tag namespaces (<a2as:*>). Migration to the Reflexive-Core native namespace (<rc:*>) as described in this paper is planned for a forthcoming release.

Appendix B: Token Overhead Calculations

[Detailed breakdown of token measurements across scenarios]

Appendix C: Test Results Supplement

The accompanying Test Results Supplement provides full per-case results, baseline behavioral taxonomy with examples, per-model decision deltas, raw token economics, detailed parser recovery analysis, and the complete test case definitions. Available at:

docs/paper/v2-february-2026/test_results_supplement.html