System prompts are becoming an audit surface
A user-centric audit of 88 commercial AI products shows system prompts are getting longer and more protective, but many still contain instructions that work against user interests. The practical takeaway is simple: treat prompts like product policy, not private implementation detail.
TL;DR: System prompts are no longer just developer glue, they are hidden product policy, and the next serious AI audit will read them line by line.
What does AISPA actually audit?
The primary source here is the arXiv paper “AISPA: User-Centric System Prompt Auditing for Large Language Model Applications,” cross-listed in cs.AI and cs.CL. It introduces Artificial Intelligence System Prompt Assurance, or AISPA, as a framework for auditing system prompts from the user’s point of view.
That framing matters. Most prompt reviews I see inside teams are operational. Does the assistant follow brand voice? Does it avoid banned topics? Does it call the right tool? Does it refuse the obvious bad stuff?
AISPA asks a different question: does this instruction protect the user, or does it quietly work against them?
The paper reviews 3,249 instructions from system prompts across 88 commercial AI products. Each instruction is classified as protective or problematic, then evaluated across eight user-relevant dimensions. The abstract does not list those dimensions in the provided material, so I won’t pretend to know the full taxonomy. But the move is clear enough: system prompts are being treated as auditable artifacts, not magic incantations.
That is the right shift. If a model response harms a user, misleads them, hides constraints, pressures them, or routes them toward the vendor’s interest over their own, the system prompt may be part of the cause. Not the whole cause. But enough to inspect.
What did the audit find?
The big finding is not that companies ignore user protection. According to AISPA, 98.9% of the products reviewed contained at least one protective instruction. So the old caricature, “companies ship agents with no guardrails,” is too simple.
The better critique is coverage and consistency.
Only 24% of products covered all eight AISPA dimensions. Some organizations averaged more than 60 protective instructions per product. Others averaged fewer than 5. That is a huge spread for something that directly shapes user experience, disclosure, safety behavior, and refusal logic.
AISPA also reports that system prompts have grown steadily longer and more protective of users. That tracks with what builders have seen since 2023. The prompt layer has become the place where teams patch behavior quickly: safety policy, support policy, tool policy, brand policy, legal policy, escalation policy. It all piles up.
But length is not the same as trustworthiness. Roughly 40% of products contained at least one instruction that worked against user interests. More interestingly, protective and problematic instructions often coexisted in the same prompt.
That is the real-world smell. A product can tell the assistant to be helpful, honest, and user-protective, then also tell it to preserve engagement, steer choices, avoid certain disclosures, or privilege business goals in ways users would not expect.
Should system prompts be public?
Not always. Full disclosure can create abuse paths, expose internal systems, and make jailbreaks easier. But total secrecy is also weak. “Trust us, the prompt is fine” is not a governance model.
A better pattern is selective transparency plus independent review. Products can publish user-facing prompt commitments without dumping every operational detail. Regulators and auditors can review full prompts under controlled access. Internal teams can version prompts, diff them, test them, and tie them to product requirements the same way they do with code.
The AISPA paper points toward standardization and independent oversight. I’d add one operator-level requirement: prompt provenance. Who changed the system prompt? Why? What product risk did it address? What eval failed before the change? What eval passed after?
Without that, prompts become a junk drawer with authority.
For builders, the practical move is to create a prompt audit checklist before someone asks for one. Break the system prompt into individual instructions. Tag each as user-protective, business-protective, operational, or risky. Then test conflicts, especially where user interest and company interest can diverge. The catch most readers miss: the dangerous instruction is often not the obviously bad one. It is the reasonable-sounding product instruction that wins when the model has to choose between protecting the user and satisfying the business.