OpenAI Decisions API and llm-openai-decisions Plugin: A Defender's Guide to Governing New LLM Decision Endpoints

OpenAI has shipped its new Jev-style Decisions API, announced at last week's DevDay, and within days the developer ecosystem has begun producing integration tooling — including llm-openai-decisions 0.1a0, an alpha-stage plugin for Simon Willison's llm CLI framework. Notably, the plugin was itself written by an LLM (GPT-6 Astra) reading the API documentation, and the new gpt-6-luna decision model accepts image input in addition to text, with a billing model that charges for input tokens only (10 cents per million input tokens, output free).

Nothing here is a vulnerability. There is no CVE, no exploit, no adversary. But from a defensive standpoint, this news item is a textbook example of how shadow AI enters the enterprise: a brand-new API surface, a community plugin at version 0.1a0 (explicitly alpha), AI-generated code, a novel data path (images into a hosted model), and a billing structure that changes the abuse economics. If your engineers are experimenting with LLM tooling — and they are — this class of release will land on your endpoints and in your CI pipelines whether you approve it or not. The time to set guardrails is before the first incident, not after.

Technical Analysis: What Changed and Why Defenders Should Care

The API surface. OpenAI's Decisions API exposes a hosted decision-making model (gpt-6-luna) that accepts both text and image input. Every new hosted model endpoint is a new egress destination for corporate data. Image input is the meaningful delta: screenshots, whiteboard photos, scanned documents, and architecture diagrams frequently contain credentials, internal hostnames, customer PII, and regulated data (HIPAA, PCI-DSS scope) that text-only workflows never touched.

The plugin supply chain. llm-openai-decisions is distributed via GitHub/PyPI at version 0.1a0. Three supply-chain observations from a veteran's seat:

1. Alpha-stage code in the dependency tree. An 0.1a0 release has no stable API contract, no security track record, and will be pulled into developer environments via pip install without any review gate unless you impose one.
2. AI-generated code. The plugin was authored by GPT-6 Astra from API documentation. LLM-authored code is not inherently insecure, but it bypasses the traditional author-accountability model and can harbor subtle issues — overly broad error handling, credential leakage into logs, unvalidated input passed to the API — that human reviewers may gloss over because the code 'looks clean.'
3. API key handling. Any llm-framework plugin inherits the framework's key storage model. Keys for the Decisions API will land in plaintext config files, environment variables, and shell histories on developer workstations — the same places infostealer malware has been harvesting cloud credentials from for years.

The billing model. Charging for input only (10 cents per million tokens) inverts the usual cost-abuse calculus. A leaked or abused API key attached to a model that ingests images at scale is a financial and data-exposure risk simultaneously — and 'free output' removes one of the natural cost signals that historically alerted finance teams to key abuse.

Exploitation status: None. This is a capability release, not a vulnerability. The risk is governance, not exploitation.

Executive Takeaways

1. Inventory AI egress before you try to block it. Add OpenAI's new Decisions API endpoints to your cloud/API egress monitoring. Your proxy, CASB, and DNS telemetry should be able to answer: which users and service accounts are sending data — especially image uploads — to hosted model endpoints? You cannot govern what you cannot see.

2. Extend DLP policy to image-classification, not just text. Most DLP deployments still key on text patterns (SSNs, card numbers, keywords). Image input to LLMs defeats that control entirely. If you have regulated data, mandate that image-to-LLM workflows route through an approved gateway with OCR-based inspection, or block image uploads to unapproved AI endpoints outright.

3. Gate PyPI/npm installs of AI plugins through your package proxy. A developer running pip install llm-openai-decisions should hit your internal artifact repository (Artifactory, Nexus, etc.), where alpha/pre-release packages can be held for review. Pre-release versions (a0, b0, rc) of newly published packages are a classic typosquatting and dependency-confusion window — the legitimate plugin existing means the malicious lookalike is likely days behind.

4. Treat LLM API keys like cloud credentials — because they are. Enforce storage in a secrets manager (not ~/.config, not .env files committed to repos), set per-key spend and rate limits in the OpenAI console, and alert on anomalous input-token volume. With input-only billing, a usage spike is your exfiltration indicator.

5. Require human security review for AI-generated dependencies. Update your secure SDLC policy: code authored by LLMs — like this plugin — receives the same third-party code review as any external contribution. Specifically audit for: how API keys are read and logged, what data is sent in requests, and whether error paths leak prompt or image content.

6. Brief your IR team on LLM tooling artifacts now. If you haven't already, add llm CLI config paths, Python site-packages inventories for AI plugins, and API-key files to your forensic collection playbooks. When a key leak or data-exposure incident happens, your responders need to know where these tools live on disk.

Remediation and Hardening Steps

This is a governance exercise rather than a patch cycle, but the actions are concrete:

• This week: Query your egress/proxy logs for OpenAI API domains over the past 30 days. Establish the baseline of who is already using LLM APIs and from where.
• This week: Confirm your package-management proxy blocks or quarantines pre-release packages by default for non-sandbox environments.
• Within 30 days: Publish (or update) an acceptable-use policy covering image input to hosted AI services, with an explicit data-classification matrix — what may never leave the network regardless of the tool.
• Within 30 days: Enforce spend caps and alerting on all organizational OpenAI API keys; rotate any keys found in developer home directories or shell history.
• Ongoing: Subscribe to release feeds for AI tooling your developers use (GitHub release watches are free) so a 0.1a0 doesn't become a production 0.3 dependency without a review checkpoint.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub