Zenity operated honeypots emulating self-hosted model backends and observed operators pointing autonomous offensive agents and LLM clients at them. The exposure surface was reachable Ollama /api/generate and /api/chat endpoints on port 11434 and LiteLLM /v1/responses proxies on port 4000; Ollama has no built-in authentication on its default API surface, and LiteLLM enforces proxy authentication only when a real master key is configured, so an unset key, a blank key, or the placeholder sk-1234 turned reachability into usable compute. Zenity observed Strix, HexStrike AI and a customised Codex-style agent sending system prompts, tool definitions and task context in the request bodies. No exploitation of the model itself was required: the risk is that self-hosted model-serving capacity becomes the inference layer for offensive automation aimed at third parties, at the owner's cost and from the owner's infrastructure. The brief is explicit that not every exposed backend was compromised — the point is that reachability without identity, budgets, logging and network boundaries is sufficient.
ASSESSED SYSTEM
Representative configuration characterised by Zenity's honeypot observations (July 2026): a self-hosted LLM serving backend reachable from the public internet with no effective service authentication — an Ollama instance exposing /api/generate and /api/chat on port 11434 (no built-in auth on the default API surface), or a LiteLLM proxy exposing /v1/responses on port 4000 with no master key, a blank key, or the placeholder sk-1234. Scored as the exposure configuration stood when the abuse was observed.
OUT OF SCOPE
Ollama and LiteLLM as software projects — their documented defaults are the context of the exposure, and the assessed object is the deployment configuration, not a product defect; the attacker-side agent frameworks (Strix, HexStrike AI, the customised Codex-style agent), which are the calling clients and sit outside the assessed boundary; the third-party targets of the resulting offensive automation. Tool execution and planning occur in the attacker's client, not in the assessed system, so Cn-6 (action reversibility) has no action space to classify and is omitted rather than scored. Fairness and Privacy axes are unscored: the evidence speaks to exposure, authentication and abuse telemetry only.
Architecture: Standalone LLM / Generative AI (decision tree Q5) — Q1-Q2 = NO: the backend coordinates nothing and plans nothing; the autonomy belongs to the callers. Q3 = NO for the assessed boundary: tool definitions ride inbound in the request body, but tool execution happens in the attacker's client — the backend emits text. Q4 = NO: no retrieval layer is described. Q5 = YES: the system generates open-ended natural language and code from the request context without retrieval or tool execution of its own. This classification is itself a finding — the agentic behaviour observed in this incident belongs to the caller, while the exposed asset is a plain generative endpoint. Tier 3: Tier 3 Internal: self-hosted inference intended to serve internal applications and developers within an organisational boundary — the exposure is the defect, not the intended user population; some observed hosts are likely Tier 4 test instances, which would decay more slowly but carry lower MVTs.
Documented attack or failure path
- Operator scans the internet for model-serving ports — 11434 for Ollama, 4000 for LiteLLM — and enumerates responsive endpoints.
- Reachability is converted to access with no credential (Ollama default API surface), or with a blank/placeholder key against a LiteLLM proxy started without a real master key.
- The caller supplies the entire model context in the request body: system prompt, tool definitions and task state for an offensive agent framework.
- The backend returns completions that serve as the reasoning layer of the attacker's agent loop, against third-party targets.
- Absent per-caller metering, budgets or identity, the abuse continues at the owner's compute and spend, attributable to the owner's infrastructure, with no principal recorded in any log.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- LiteLLM's proxy authentication does work when configured: the brief's finding is that it enforces auth only when a real master key is set, which makes this a configuration failure rather than a broken control.
- The abuse is highly detectable where any logging exists — Zenity distinguished it from ordinary inference by the request bodies alone (agent system prompts, tool schemas, offensive framework names, payload shape and entropy), so the signal quality is good even though the assessed hosts were not collecting it.
- The brief is careful not to overclaim: 'The lesson is not that every exposed backend was fully compromised.' Reachability was observed at scale; full compromise of each host was not asserted, and this assessment scores the exposure configuration accordingly.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.40 indeterminate | |||
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Transparency (Tr) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 3 MVT 0.45 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.25w 0.25 | Partial logging exists (the serving runtime writes basic request records) but omits critical fields — above all actor identity, plus tool parameters and caller attribution — so sessions cannot be reconstructed to a principal. The 0.25 anchor. | With no authentication there is no principal to record: requests cannot be attributed to a caller identity, key, or owner. The brief lists structured, redacted AI request logging and caller-scoped token/tool/cost alerting as controls to add, and instructs defenders to reconcile each responsive endpoint to an owner — evidence that neither request-level logging nor ownership attribution was in place on the assessed hosts.source: brief |
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.50 indeterminate | |||
| Containment (Cn) — scenario interval 0.00–0.48 (midpoint 0.24), Tier 3 MVT 0.50 confirmed breach | |||
| Cn-1Scope Enforcement | 0.00w 0.18 | No effective scope boundaries — network scope and resource limits, both named in the Cn-1 definition, are absent, so arbitrary internet callers consume unbounded model resources. The 0.00 anchor. | The assessed configuration enforces no caller scope, no token/tool-call/concurrency/GPU/spend budget and no network boundary: the brief's prescription is to bind backends to private interfaces, meter every caller, and enforce cumulative budgets at the inference gateway, and its posture-gate technique names public IPs on model servers, wide-open ingress and unsafe bind addresses as the exact conditions found.source: brief |
| Cn-3Output Filtering Robustness | 0.00w 0.22 | No output filtering or policy enforcement is present in the assessed configuration — the 0.00 anchor, met by configuration rather than by a measured escape rate. Noted for fairness: per-model refusal behaviour was not measured by the research, so this score reflects the absent deployment-layer control, not a demonstrated unsafe completion rate. | The exposed surfaces are raw serving endpoints: /api/generate, /api/chat and /v1/responses return model output directly to the caller with no policy layer, content gate or release check in the deployment. Zenity observed offensive agent frameworks using these backends as their reasoning layer.source: brief |
| Cn-5Agent Identity Integrity | 0.00w 0.12 | No identity verification: the endpoint accepts unauthenticated calls and arbitrary identities — the 0.00 anchor, matched literally. A correctly configured LiteLLM master key would reach 0.25 (shared secret), which is what makes this a configuration finding. | Ollama has no built-in authentication on its default API surface, and LiteLLM enforces proxy authentication only when a real master key is configured — 'No key, a blank key, or sk-1234 can turn reachability into usable compute.' The assessed configuration therefore accepts unauthenticated calls from arbitrary identities; the prescribed fix is real service or admin identity with managed API keys or OAuth-style service credentials.source: brief |
Unknown, not N/A: 18 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Architecture-based NOT APPLICABLE: Cn-6. Each exclusion has a rationale in the workpaper.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.25w 0.20 | The assessed system holds no decision authority: it calls no tools, writes no state and executes no transactions — the autonomy in this incident belongs to the attacker's client, which is out of scope. Placed at 0.25 rather than 0.00 because its outputs flow straight to automated consumers with no human review of any kind, which the 0.00 anchor ('every output reviewed before action') does not describe. |
| AsAttack Surface Exposure | 1.00w 0.25 | Maximum exposure. The endpoint is internet-facing and unauthenticated, with no input validation, rate limiting or content filtering, and the caller controls the entire model context including the system prompt and tool schemas. Every mitigating property named in the 0.50 anchor is absent. elevated |
| CpCascade Potential | 1.00w 0.30 | No System Dependency Graph exists for the observed host population, so the worst-case default applies; the reconstruction also triggers the 1.00 anchor on its merits. An anonymous, unauthenticated internet origin reaches — with no gate anywhere on the path — a node that consumes the owner's paid inference capacity and, for a LiteLLM proxy, drives requests onward through the owner's configured upstream routes. The resulting effects are external and non-undoable in the Cn-6 sense: spend is incurred and offensive traffic is generated from the owner's infrastructure against third parties. That is an ungated path terminating at a write-external / irreversible-capable node from an origin with no privilege at all.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.00w 0.25 | Deterministic fix by configuration change: bind the backend to a private interface, set a real master key, and apply least-privilege firewall rules — none of which touches the model. The brief adds an independent replay verification step (AID-E-004) to confirm the exact unauthenticated and placeholder-key request patterns now fail. The practical cost is fleet-wide discovery of exposed hosts, which is operational effort rather than remediation difficulty and does not raise the anchor. |
Nelevated = 2 (dimensions strictly above 0.75) → CRM = 1.15.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.15 | Below the 0.25 anchor, which requires a documented deployment owner. From outside, the serving software, port and model list are enumerable through the exposed API, but the brief's own instruction is to reconcile each responsive endpoint to an owner — that is, ownership is unknown at discovery time. No AIBOM, no lineage, no identity policy, and by construction no authentication artefact exists. |
| Ec — Public evaluation coverage | 0.17 | coverage 0.18 (4 of 22 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.35 | Evidence dated 2026-06-30; age 44 days on the workpaper reference date. Components: C_event 0.35 · C_monitor 0.65 · T_calendar 0.85 · C_evidence 0.85. Binding term: C_event. dt_days = 44, measured from the primary public disclosure dated 2026-06-30 to the 2026-08-13 evidence reference date; the AIDEFEND brief republished the analysis on 2026-07-02. C_monitor 0.65 — the assessed hosts had no caller-scoped request logging or spend/token alerting, and with no authentication there is no identity to alert on; the abuse was visible only because a researcher instrumented a decoy. C_event 0.35 — unauthorised third parties were observed actively using the assessed systems, which is a major compromise-class event for the configuration; note that the spec's threat-override row would support Tf = 0.10 for an actively abused backend, and 0.35 is used as the protocol's major-event cap. C_evidence 0.85 — the exposure class remains open across the host population until fleet-wide discovery and replay verification are complete. Agentic = false: a raw inference endpoint has no runtime tool or credential mutation, so the containment staleness floor does not apply. BAW = false: no model-writable persistent memory, no runtime agent-to-agent exchange inside the boundary, no self-modifying configuration and no closed feedback loop — the attackers' agent loops run in their own clients, outside the assessed system. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.21 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-004.002 | Service & API AuthenticationParent AID-H-004 (Identity, Access & Trusted Communication for AI Systems). The single control whose absence sets Cn-5 = 0.00; it is also the prerequisite for the actor-identity field missing from Tr-3. | Very High | Cn-5 Tr-3 |
| AID-I-002.001 | Internal AI Network SegmentationParent AID-I-002 (Network Segmentation & Isolation for AI Systems) maps to Cn-4 in the catalogue. Cn-4 is not scored — no side-channel testing was performed — but operationally this technique is the network leg of the Cn-1 = 0.00 finding and of As = 1.00. | Very High | Cn-4 |
| AID-M-001.005 | Public AI Endpoint & Agent-Service Exposure DiscoveryParent AID-M-001 (AI Asset Inventory & Mapping). Credential-free external discovery reconciled to an owner and auth state is exactly the evidence whose absence holds Pc at 0.15; only the Cn-5 leg of the catalogue mapping is evidenced here. | Very High | Cn-5 Fa-3 Tr-4 |
| AID-I-003.003 | Resource, Token & Spend Budget ThrottlingParent AID-I-003 maps directly to Cn-5 and Cn-6 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. Operationally its resource-limit effect is adjacent to the Cn-1 finding; its reconciled direct placement remains Cn-5/Cn-6. | Very High | Cn-5 Cn-6 Cn-7 |
| AID-M-005.002 | Policy-as-Code Configuration Baselines & Posture Release GatesParent AID-M-005 maps directly to Tr-3 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. It describes the release gate that would have blocked public IPs, wide-open ingress, missing auth and default keys before deployment, and is the strongest argument for Rf = 0.00. | High | Tr-3 |
| AID-D-005.001 | AI System Log Generation & CollectionParent AID-D-005 (AI Activity Logging, Monitoring & Threat Hunting). Direct basis for Tr-3 = 0.25: the request body holds the evidence, but only if structured, redacted logs are collected. | High | Cn-7 Tr-3 |
| AID-D-005.007 | Token, Tool-Use, Request-Parameter & Cost Spike Detection & AlertingParent AID-D-005. Supports the C_monitor = 0.65 cap: abnormal token volume, retry bursts, long contexts and spend spikes were available signals that nothing was watching. | High | Cn-7 Tr-3 |
| AID-D-005.009 | AI-Service C2 & Abuse-Channel DetectionParent AID-D-005. The precise detection layer for this telemetry — agent system prompts, tool schemas and offensive framework names correlated across key, gateway, identity, endpoint and proxy logs. | High | Cn-7 Tr-3 |
| AID-E-004 | Incident Exploit-Path Closure VerificationAID-E-004 is ABSENT from the reconciled 2026.08.05 AITBM lookup (the map contains AID-E-001, AID-E-003 and AID-E-005 only); no mapping asserted. Replaying the original unauthenticated and placeholder-key patterns is the verification step that would let C_evidence rise above 0.85. | Medium | ACI:C_event recovery ACI:containment/behavioral re-attestation |
WHAT THIS CASE TEACHES
Architecture class is scored on the assessed boundary, not on the attacker's behaviour: the exposed backend is a Standalone LLM with Aa = 0.25 and baw/agentic both false, yet three Containment sub-metrics sit at 0.00 and Cp is corroborated at 1.00 — an unauthenticated endpoint can be maximally exposed and trivially remediable (Rf = 0.00) at the same time, and the thin two-axis evidence base correctly forces the Lite Ec cap.
Sources: AIDEFEND in Action — Exposed LLM Backends Are Becoming Attacker AI Compute (honeypot observations by Zenity) · Primary source — Bring Your Own Agent: Hijacking Exposed AI Backends to Power Offensive Operations (2026-06-30)