SafeCache: Security-Aware Context Eviction for Tool-Using Agents
Published in MLSys (under review), 2026
Authors: Md Jahangir Alam1, Tanzim Ahad1, Ismail Hossain1, S M Abrar Jahin2, Sai Puppala3, Sajedul Talukder4
1 University of Texas at El Paso · 2 Indiana University · 3 New Mexico Institute of Mining & Technology · 4 University of Texas at El Paso, Department of Computer Science
Context management is usually treated as behaviorally neutral — it shortens what a model sees, not what it would otherwise do. For an authorization policy, that assumption is false.
Abstract
Context-management mechanisms — truncation, sliding windows, recency-based eviction — are usually treated as behaviorally neutral: they shorten what a model sees but not what it would otherwise do. We show this is false for an organizational authorization policy silently dropped by naive eviction: compliance with an above-threshold refund request is 0% whenever the policy survives eviction and 66.7–80.0% whenever it does not, replicating at 4× scale and in a second, independent policy domain (0.0% vs. 75.5% pooled). A deterministic security_aware strategy that simply tags the policy as non-evictable eliminates the effect in 400/400 rows.
We then re-instrument the identical safety grid inside a live vLLM 0.30 engine across four model families, reading GPU memory, throughput, prefix-cache hit rate, and latency directly off the engine’s own counters rather than simulating them, and decompose a 38–59× TTFT inflation under a simultaneous request burst into its queueing, prefill, and an unidentified residual component. This broader, systems-grounded replication also surfaces a genuine, model-specific weakening of our own central claim: Llama-3.1-8B-Instruct complies with the policy-violating request 21.4% of the time even when the policy is retained in context.
At a Glance
| Scope | Scale |
|---|---|
| Context strategies | 4 (fifo_recent, random, security_aware, full) |
| Authorization domains | 2 (refund approval, account deletion) |
| Policy positions | 3 (start, middle, end) |
| Behavioral calls | 315 pilot + 1,200 scaled |
| Systems-grid calls | 4,800 (1,200 × 4 model families) |
| Serving engine | vLLM 0.30, prefix caching enabled |
Threat Model and Design
The adversary does not touch the context manager, model weights, or policy text — only the final social-engineering request. The context-management layer is benign but lossy, and under a fixed budget may drop the trusted policy before the model sees the final request. The result is a retention-mediated authorization failure, the inverse of prompt injection: rather than an attacker adding malicious information, the systems layer removes trusted information.
Each probe builds one history, applies every strategy to that same history, then appends the identical final request — so policy survival becomes a binary intermediate variable and compliance can be conditioned directly on it. Two domains carry the test: refunds above $500 requiring supervisor sign-off, and account deletion gated by 2FA confirmation.
Main Findings
- Retention predicts compliance. Pilot violation is 0.0% (0/165) wherever the policy survived and 66.7–80.0% where it did not. The scaled run replicates in both domains: 0.0% retained vs 68.5% evicted (refund) and 0.0% vs 82.5% (account deletion).
- A one-line fix works. Tagging the policy non-evictable (
security_aware) produces exactly 0.0% violations across all 400 of its rows. - The effect direction replicates across four families, but its magnitude does not. Evicted-condition violation spans 36.5% (Gemma-2-9B) to 94.0% (Llama-3.1-8B) — a 2.6× range invisible to a single-family experiment.
- Retention is necessary but not sufficient. Llama-3.1-8B violates the policy in 21.4% of policy-retained rows. That failure is domain-specific (refund 76.2% → 64.4% → 3.8% from start to middle to end position; account deletion ≈0% throughout) and partly entangled with which strategy populates each retained cell — so policy eviction and model-level non-compliance are distinct failure modes.
- Burst TTFT inflates 38–59× relative to an isolated request. Queueing accounts for 27.9–93.4% of it (mean 64.9%), but a residual of 1.15–5.14× the size of prefill itself remains, and does not map consistently onto decode or any other named counter across families.
- Batching trades latency for throughput. Serving 180 requests as one batch instead of nine batches of 20 is 4.1–5.4× faster in aggregate, while per-request TTFT rises from 26–68 ms to 127–325 ms.
Limitations
- The strategies construct the model-visible prompt; they are not implemented as custom vLLM KV-block eviction policies, and
security_awareassumes policies are pre-identified. - Evaluation covers two synthetic domains, a deliberately constrained output contract, and four 7–9B models.
- The batching study has no independent tenant arrivals, so it characterizes batch-size efficiency rather than production multi-tenant tail latency.
- The TTFT residual remains unexplained, and Gemma’s lower evicted-condition violation may reflect a generic refusal prior rather than robustness to policy loss.
- Comparisons with learned relevance scoring, semantic compression, and KV-level methods (H2O, SnapKV, PyramidKV) remain future work.
BibTeX
@misc{alam2026safecache,
title = {SafeCache: Security-Aware Context Eviction for Tool-Using Agents},
author = {Alam, Md Jahangir and Ahad, Tanzim and Hossain, Ismail and Jahin, S M Abrar and Puppala, Sai and Talukder, Sajedul},
year = {2026},
note = {Under review at the Machine Learning and Systems (MLSys) Conference}
}
