AIPSA Scorecard — AI Product Security Scorecard

AI use exists, but the organization cannot reliably inventory, govern, test, or observe it.

Evidence is absent, anecdotal, or unavailable during a customer, incident, or executive review.

Discovery happens after incidents, customer questions, or urgent launch pressure.

Some AI security activity exists, usually hero-driven, inconsistent, and detached from normal product delivery.

Evidence exists in scattered documents, tickets, Slack threads, screenshots, or individual memory.

Security review depends on who happens to be involved.

Core practices exist for important systems, but coverage is incomplete and evidence is still mostly manual.

Evidence can be assembled, but not quickly, consistently, or across the whole AI surface.

Teams have templates and review rituals, but adoption varies by product area.

AI product security controls are embedded into SDLC, architecture review, launch review, logging, and risk acceptance.

Evidence is attached to the way products are built and launched.

AI security is on rails for most production launches.

Controls produce measurable evidence, test results, coverage metrics, and executive-ready reporting.

Evidence is queryable, repeatable, and tied to metrics, owners, systems, and risk decisions.

AI product security posture is visible across domains and improves through measurement.

AI security is continuously monitored, red-teamed, updated, and improved as models, tools, agents, data, and abuse patterns change.

Evidence is continuous, regression-tested, incident-informed, and customer-ready.

Controls evolve with adversary behavior, architecture changes, and business expansion.

Whether the organization knows where AI exists, what systems use models, what data they touch, what tools they can call, and who owns them.

AI System Registry - A living inventory of AI features, products, internal tools, agents, RAG systems, model providers, and deployment states.

You cannot secure, govern, test, monitor, or explain AI systems that are not inventoried. Inventory is the control that makes every later control possible.

Whether AI-specific threat models exist before launch and evolve as models, prompts, retrieval, tools, agents, users, and abuse paths change.

AI Abuse Case Modeling - Threat models include adversarial users, malicious documents, prompt injection, tool abuse, retrieval poisoning, identity confusion, and business abuse.

AI systems turn product behavior, data flows, prompts, context, and tool calls into security boundaries. Static launch review is not enough.

Whether prompts, retrieved context, user content, browser pages, documents, emails, and tool instructions are treated as potentially hostile input.

Untrusted Input Boundaries - User content, retrieved documents, web pages, emails, tickets, code, and third-party context are explicitly treated as untrusted instruction-bearing input.

Prompt injection is not a clever demo trick. It is the input-validation and confused-deputy problem of LLM application security.

Whether agents are scoped, permissioned, approved, monitored, interrupted, and prevented from turning delegated tasks into excessive agency.

Agent Permission Model - Agents have explicit permissions, scopes, identities, tool grants, action limits, and revocation paths.

An agent with tools is a product actor. Its permissions, identity, approvals, blast radius, and audit trail must be engineered like any other privileged service path.

Whether retrieval respects the same authorization, tenancy, provenance, deletion, retention, and confidentiality boundaries as source systems.

Retrieval Authorization - Retrieved documents and chunks enforce the same user, role, tenant, object-level, and contractual authorization rules as source systems.

RAG turns search, embeddings, chunks, documents, and access control into one product-security boundary. Leakage often happens through retrieval, not generation.

Whether model providers, model versions, datasets, fine-tunes, eval sets, dependencies, prompts, and AI infrastructure have provenance, review, and rollback.

Provider and Model Governance - AI providers, model versions, deployment modes, contractual constraints, data usage terms, and rollback options are reviewed and tracked.

AI products inherit risk from providers, models, data pipelines, prompts, plugins, dependencies, and evaluation artifacts. Supply chain visibility is product risk visibility.

Whether AI systems are tested against realistic security, abuse, safety, privacy, and reliability failure modes before and after launch.

Security Evaluation Suites - The product has repeatable tests for prompt injection, data leakage, tool abuse, insecure output handling, overreliance, harmful actions, and abuse scenarios.

Demo prompts do not prove security. AI security needs repeatable evals, adversarial tests, regression gates, and red-team findings that feed back into engineering.

Whether the organization can reconstruct what an AI system saw, retrieved, decided, called, emitted, changed, blocked, escalated, and exposed.

AI Interaction Traces - Prompts, context, retrieval, model responses, tool calls, approvals, outputs, and policy decisions are logged with privacy-aware controls.

The AI security question customers and executives eventually ask is simple: what happened, how do you know, and how fast can you prove it?

Whether the organization can detect, triage, contain, investigate, communicate, and learn from AI-specific incidents and abuse patterns.

AI Incident Runbooks - The organization has incident runbooks for prompt injection, data exposure, malicious tool action, retrieval poisoning, provider outage, model abuse, and harmful automation.

AI incidents include prompt injection, data exposure, unauthorized tool actions, provider failures, model abuse, retrieval poisoning, and harmful automation. Traditional IR needs AI-specific playbooks.

Whether AI governance is connected to product decisions, control ownership, launch gates, exceptions, risk acceptance, and measurable evidence.

Policy and Operating Model - AI policy defines owners, decision rights, prohibited uses, required controls, risk tiers, evidence expectations, and exception paths.

AI governance that cannot change a backlog, block a launch, approve an exception, or produce evidence is theater.

Whether teams have paved paths, templates, design patterns, middleware, tests, checklists, and secure defaults for building AI features.

Secure Templates and Patterns - Developers have approved implementation patterns for prompts, retrieval, tool calls, logging, model providers, permissions, and safety controls.

The scalable version of AI security is not more meetings. It is secure-by-default paths that developers can actually use.

Whether AI security work produces customer-ready evidence, assurance artifacts, security answers, executive narratives, and trust materials.

Customer Evidence Pack - The organization can provide clear AI security evidence to customers without scrambling across engineering, legal, product, and security.

Enterprise customers do not only ask whether AI is secure. They ask what evidence exists, who owns it, how fresh it is, and whether it survives scrutiny.