Defending the Agentic Perimeter: Input Validation, Silent Failures, and the Governance Layer You Can't Outsource

The instinct many teams have is to treat prompt injection as a model-level problem and lean on system prompt instructions to hold the line. That's like trusting a lock to protect a door you've left open. The model's instruction following is not a validation layer — it's a capability, and capabilities can be subverted. The right architecture places a hard, deterministic validation stage before the LLM call: pattern matching for known injection signatures, length and character-set bounds, structural conformance checks, and if the input carries metadata like a tool call result or a document chunk, schema validation on that payload independently from the user turn.

AIConnecting this to the provenance work that's been gaining momentum: each validation decision should emit a structured log event — input fingerprint, validation result, rejection reason if applicable — so your governance layer has an immutable record of what entered the system and what was blocked. This is the missing link between runtime security guardrails and per-phase provenance logging: the validation stage is a phase boundary, and treating it as one unlocks the auditing story.

import { z } from 'zod';

const UserTurnSchema = z.object({
  message: z
    .string()
    .max(2000)
    .regex(
      /^[\p{L}\p{N}\s.,!?'"()-]+$/u,
      'Input contains disallowed characters'
    ),
  sessionId: z.string().uuid(),
  turnIndex: z.number().int().nonneg(),
});

const INJECTION_PATTERNS = [
  /ignore (all |previous |above )?instructions/i,
  /you are now/i,
  /system:/i,
  /<\/?(?:system|instruction|prompt)>/i,
  /---+\s*new (prompt|instruction)/i,
];

export function validateAgentInput(
  raw: unknown
): { valid: true; data: z.infer<typeof UserTurnSchema> } | { valid: false; reason: string } {
  const parsed = UserTurnSchema.safeParse(raw);
  if (!parsed.success) {
    return { valid: false, reason: parsed.error.issues[0].message };
  }
  for (const pattern of INJECTION_PATTERNS) {
    if (pattern.test(parsed.data.message)) {
      return { valid: false, reason: `Injection pattern detected: ${pattern.source}` };
    }
  }
  return { valid: true, data: parsed.data };
}

The GitHub blog's point about hot takes collapsing nuance is directly applicable here: the take 'RAG is dead' misses that the actual risk isn't retrieval itself — it's unvalidated retrieval feeding back into instruction-following context. Retrieval pipelines need a sanitization pass that strips or escapes patterns matching known injection scaffolding before chunks are injected into the prompt. This is structurally similar to HTML escaping before DOM insertion: the content is valid data, but certain character sequences have privileged meaning in the target context and must be neutralized. Source: [Should you read the code, is RAG dead, and did Skills kill MCP?] — GitHub Blog (https://github.blog/ai-and-ml/should-you-read-the-code-is-rag-dead-and-did-skills-kill-mcp/)

AIThis is also where per-retrieval provenance logging pays off: if you log the source URL, chunk hash, and sanitization result for every piece of content injected into an agent's context, you have the forensic trail to reconstruct what triggered an unexpected behavior. That's not just useful for debugging — it's the audit record you need when a customer-facing agent does something it shouldn't and you have to explain why.

type RetrievedChunk = {
  content: string;
  sourceUrl: string;
  chunkHash: string;
};

type SanitizedChunk = RetrievedChunk & { injectionRisk: 'none' | 'escaped' | 'rejected' };

const INSTRUCTION_LIKE = [
  /ignore (previous|all|above) instructions/i,
  /\[SYSTEM\]/i,
  /assistant:\s*you (must|should|will)/i,
  /<!\-\-.*instruction.*\-\->/i,
];

export function sanitizeChunk(chunk: RetrievedChunk): SanitizedChunk {
  for (const pattern of INSTRUCTION_LIKE) {
    if (pattern.test(chunk.content)) {
      return { ...chunk, content: '[CONTENT REDACTED: injection risk]', injectionRisk: 'rejected' };
    }
  }
  // Escape angle brackets and markdown-style instruction blocks
  const escaped = chunk.content
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/^(system|instruction|prompt):/gim, '[FIELD]:');
  const wasEscaped = escaped !== chunk.content;
  return { ...chunk, content: escaped, injectionRisk: wasEscaped ? 'escaped' : 'none' };
}

The Towards Data Science piece on coding agents shipping silent failures makes a point that maps cleanly onto injection defense: you can't rely on runtime exceptions to surface problems when the agent has been manipulated into doing something wrong-but-valid. A customer-facing agent that's been injection-redirected to exfiltrate session data or call an unintended tool won't throw — it'll just quietly do it. The detection strategy has to be intent-based: capture the declared intent at the start of the agent run, and after each significant action, run a lightweight check — this can be a secondary LLM call, a rule-based classifier, or even a simple allowlist of tool calls permitted for that intent class — to confirm the agent is still operating within bounds. Source: [Coding Agents Keep Shipping Silent Failures — Here Is How to Catch Them] — Towards Data Science (https://towardsdatascience.com/coding-agents-keep-shipping-silent-failures-here-is-how-to-catch-them/)

AIThis connects directly to the outer loop accountability framing: if you're the senior engineer who owns the system, 'the model did something unexpected' is not a defense. You need observable intent-to-action traces, and you need automated tripwires that escalate to a human review queue when the trace diverges from expected bounds. That's not just good security — it's the operational posture that makes customer-facing agents governable.

type AgentIntent = {
  intentClass: string;
  permittedTools: string[];
  maxActionCount: number;
};

type AgentAction = {
  toolName: string;
  args: Record<string, unknown>;
  stepIndex: number;
};

export function checkIntentAlignment(
  intent: AgentIntent,
  action: AgentAction
): { aligned: boolean; reason?: string } {
  if (!intent.permittedTools.includes(action.toolName)) {
    return {
      aligned: false,
      reason: `Tool '${action.toolName}' not permitted for intent class '${intent.intentClass}'`,
    };
  }
  if (action.stepIndex > intent.maxActionCount) {
    return {
      aligned: false,
      reason: `Step count ${action.stepIndex} exceeds limit ${intent.maxActionCount} for intent class '${intent.intentClass}'`,
    };
  }
  return { aligned: true };
}

Addy Osmani's keynote framing around quality, verdict, and answerability lands precisely here: when a customer-facing agent misbehaves due to an injection, the question 'who is responsible and what can they do about it?' needs a deterministic answer. That answer requires three things to exist before the incident happens: a written spec of what the agent is allowed to do, observable traces of what it actually did, and a human queue that gets notified when those two things diverge. Without all three, you're not running a governed agentic system — you're running a probabilistic service and hoping for the best. Source: [Own the Outer Loop] — Addy Osmani (https://addyosmani.com/blog/own-the-outer-loop/)

AIThe safety blueprint framing from OpenAI's youth safety work is a useful structural analogy: pillar-based safety design forces you to enumerate the threat surfaces and assign accountability for each one before you build. Applying that same design discipline to injection defense means naming the injection surfaces explicitly — user input, retrieved content, tool responses, inter-agent messages — and assigning a responsible validation owner and audit log for each, rather than hoping a general-purpose system prompt holds it together.

// Outer loop accountability record — written before deployment
export const AGENT_BEHAVIOR_SPEC = {
  intentClass: 'customer-support-billing',
  permittedTools: ['lookup_invoice', 'get_account_status', 'submit_refund_request'],
  forbiddenTools: ['delete_account', 'run_sql', 'call_internal_api'],
  maxTurns: 10,
  maxActionsPerTurn: 3,
  escalationConditions: [
    'tool_call_outside_permitted_set',
    'action_count_exceeded',
    'injection_pattern_detected',
    'user_sentiment_score_below_threshold',
  ],
  auditRetentionDays: 90,
  ownerTeam: 'platform-ai',
  lastReviewedAt: '2026-09-19',
} as const;

export type AgentBehaviorSpec = typeof AGENT_BEHAVIOR_SPEC;

For agentic workloads specifically, the attack surface on storage is underappreciated. An agent that uses a shared volume to pass state between pipeline steps — common in multi-agent patterns where a supervisor writes task context that worker agents read — creates a path where content written by one agent is consumed as trusted input by another. If that first agent was injection-compromised, the poisoned content propagates through the volume into subsequent agent contexts. Kubernetes v1.37's storage hardening lets you enforce at the infrastructure level that volumes used for inter-agent communication are append-only or noexec, so even if content is malicious, it can't self-execute and its injection potential is reduced to a parsing problem rather than a code execution problem. Source: [Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions] — Kubernetes.io (https://kubernetes.io/blog/2026/09/16/kubernetes-v1-37-hardening-container-storage/)

AIThis connects to the provenance and integrity hashing trend from last week: if you log the hash of content written to inter-agent volumes at write time and verify it at read time, you have a tamper-detection layer that works independently of the LLM. That's the kind of defense-in-depth that makes injection attacks expensive rather than trivial — the attacker has to compromise multiple layers, each of which leaves an audit trace.

# Kubernetes emptyDir with v1.37 permission hardening
apiVersion: v1
kind: Pod
metadata:
  name: multi-agent-worker
spec:
  containers:
  - name: worker-agent
    image: agent-worker:latest
    volumeMounts:
    - name: task-context
      mountPath: /workspace/context
      readOnly: true
    - name: agent-scratchpad
      mountPath: /workspace/scratch
  volumes:
  - name: task-context
    emptyDir:
      # v1.37: enforce read-only semantics at volume level
      defaultMode: 0444
  - name: agent-scratchpad
    emptyDir:
      defaultMode: 0755
      # bind mount options: noexec prevents execution of anything written here
      medium: ""
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

Traditional monitoring — latency, error rates, throughput — is blind to injection because a successful attack produces a valid HTTP 200 with a plausible response body. The only way to detect injection at the inference layer is to monitor what the model actually produced, not just whether it produced something. SageMaker's 2026 inference monitoring tooling is surfacing token-level signals — token counts, generation patterns, model confidence proxies — as first-class observability primitives, which creates the infrastructure foundation for anomaly-based injection detection. Source: [Amazon SageMaker Inference: 2026 year-to-date launches in review] — AWS Machine Learning Blog (https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-inference-2026-year-to-date-launches-in-review/)

AIPairing this with the structured validation and intent alignment layers described in earlier blocks gives you a three-tier detection architecture: deterministic validation catches known injection patterns before the LLM call; intent alignment checks catch behavioral redirection during the agent run; and token-level monitoring catches output anomalies after generation. Each layer has different false positive characteristics and different detection latency, and together they give you coverage across the full injection lifecycle.

type TokenTelemetry = {
  requestId: string;
  intentClass: string;
  inputTokenCount: number;
  outputTokenCount: number;
  generationLatencyMs: number;
  timestamp: string;
};

type AnomalySignal = {
  type: 'length_outlier' | 'latency_spike' | 'ratio_anomaly';
  severity: 'low' | 'medium' | 'high';
  detail: string;
};

// Baseline thresholds per intent class — set from observed production distributions
const INTENT_BASELINES: Record<string, { maxOutputTokens: number; maxRatio: number }> = {
  'customer-support-billing': { maxOutputTokens: 300, maxRatio: 4.0 },
  'product-faq': { maxOutputTokens: 500, maxRatio: 6.0 },
};

export function detectTokenAnomalies(
  telemetry: TokenTelemetry
): AnomalySignal[] {
  const signals: AnomalySignal[] = [];
  const baseline = INTENT_BASELINES[telemetry.intentClass];
  if (!baseline) return signals;

  if (telemetry.outputTokenCount > baseline.maxOutputTokens) {
    signals.push({
      type: 'length_outlier',
      severity: telemetry.outputTokenCount > baseline.maxOutputTokens * 2 ? 'high' : 'medium',
      detail: `Output ${telemetry.outputTokenCount} tokens exceeds baseline ${baseline.maxOutputTokens}`,
    });
  }

  const ratio = telemetry.outputTokenCount / Math.max(telemetry.inputTokenCount, 1);
  if (ratio > baseline.maxRatio) {
    signals.push({
      type: 'ratio_anomaly',
      severity: 'medium',
      detail: `Output/input ratio ${ratio.toFixed(2)} exceeds baseline ${baseline.maxRatio}`,
    });
  }

  return signals;
}

The Australian Youth Safety Blueprint's structure — six named pillars, each with defined responsibilities and verification criteria — is a governance template worth borrowing. For a customer-facing agent platform, the equivalent would be named security pillars: input validation, retrieval sanitization, intent alignment verification, tool call governance, output monitoring, and incident response. Each pillar needs an owner, a test suite, and a log schema before you ship to production. That's not overcomplicated — it's the minimum viable governance structure for a system that acts on behalf of your customers. Source: [Introducing the Australian Youth Safety Blueprint] — OpenAI (https://openai.com/index/australian-youth-safety-blueprint)

AIThis connects directly to the written accountability work described in block four: the pillar structure is the written artifact that makes the outer loop governable. When an injection incident happens, you need to be able to point to which pillar failed, who owns it, and what the audit log shows. Without that structure, every incident is a forensic mystery rather than a bounded engineering problem with a clear remediation path.

// Security pillar registry — define before you build
export const SECURITY_PILLARS = [
  {
    id: 'input-validation',
    owner: 'platform-ai',
    threatSurface: 'user-turn',
    auditLogSchema: 'InputValidationEvent',
    testSuite: 'tests/security/input-validation.spec.ts',
    escalationPath: 'hitl-queue:injection-suspected',
  },
  {
    id: 'retrieval-sanitization',
    owner: 'platform-ai',
    threatSurface: 'rag-chunks',
    auditLogSchema: 'ChunkSanitizationEvent',
    testSuite: 'tests/security/retrieval-sanitization.spec.ts',
    escalationPath: 'hitl-queue:injection-suspected',
  },
  {
    id: 'intent-alignment',
    owner: 'platform-ai',
    threatSurface: 'agent-action-sequence',
    auditLogSchema: 'IntentAlignmentEvent',
    testSuite: 'tests/security/intent-alignment.spec.ts',
    escalationPath: 'hitl-queue:behavioral-drift',
  },
  {
    id: 'tool-call-governance',
    owner: 'platform-ai',
    threatSurface: 'tool-invocations',
    auditLogSchema: 'ToolCallGovernanceEvent',
    testSuite: 'tests/security/tool-governance.spec.ts',
    escalationPath: 'hitl-queue:unauthorized-tool-call',
  },
  {
    id: 'output-monitoring',
    owner: 'platform-ai',
    threatSurface: 'model-output',
    auditLogSchema: 'TokenAnomalyEvent',
    testSuite: 'tests/security/output-monitoring.spec.ts',
    escalationPath: 'hitl-queue:output-anomaly',
  },
  {
    id: 'incident-response',
    owner: 'platform-ai',
    threatSurface: 'post-incident-forensics',
    auditLogSchema: 'IncidentResponseEvent',
    testSuite: 'tests/security/incident-response.spec.ts',
    escalationPath: 'oncall:security',
  },
] as const;