CSPAI: Securing AI Systems from Data to Autonomous Actions

The Certified Security Professional in Artificial Intelligence (CSPAI) from SISA is a current AI-security credential developed for professionals who need to govern and protect artificial-intelligence systems. SISA describes CSPAI as an ANAB-accredited certification and positions it around practical security requirements for AI and generative AI, including risk frameworks, data protection, model behavior, applications, and operational controls.

The current program is offered through SISA’s PRISM learning platform and culminates in a Prometric-delivered exam with 50 questions, one hour of testing time, and a 70 percent passing score. The certification is maintained through continuing professional education over a three-year validity period. Candidates should verify current delivery and maintenance details at registration because the AI-security field and program structure continue to evolve.

CSPAI belongs within the broader SISA certifications. The central challenge is to stop thinking of AI security as a single “model safety” feature. Enterprise AI combines data, models, retrieval, identities, APIs, applications, infrastructure, human workflows, and sometimes autonomous tools. Each layer introduces its own trust boundary.

AI security starts by identifying the system, data, and decisions in scope

The phrase artificial intelligence covers very different systems: a classification model, a recommendation engine, a large language model, a retrieval-augmented assistant, a computer-vision service, or an agent that can call business tools. Security requirements depend on what the system can see and do.

A useful starting point is an AI conceptual model that distinguishes data, training or configuration, inference, application logic, and outputs. Generative AI adds probabilistic text or media generation, while agentic designs may add planning and tool execution. Candidates should know enough architecture to locate where a threat can enter and where a control can stop it.

Asset inventory should include models, datasets, prompts or system instructions, vector stores, APIs, plugins or tools, secrets, evaluation sets, and the applications that expose them. An organization cannot govern AI risk effectively if teams deploy models through personal accounts or unregistered SaaS services outside normal security review.

Data security applies before training, during retrieval, and after generation

AI systems often concentrate sensitive data. Training datasets may include proprietary or personal information; retrieval stores may contain internal documents; prompts may reveal confidential context; outputs may reproduce information a user is not authorized to see. Traditional classification and access-control principles therefore remain essential.

Generative AI security starts with data, identity, and access. A model should not become an alternate route around document permissions. Retrieval should enforce the user’s authorization, service accounts should have narrow access, and logging should capture enough context to investigate misuse without unnecessarily storing sensitive prompt content.

Data provenance matters as well. Teams should know where training and fine-tuning data originated, what rights govern its use, how it was cleaned, and which version produced a model. Poisoned or mislabeled data can affect behavior long before the application layer receives a user request.

Generative AI introduces prompt, retrieval, and output attack surfaces

Large language model applications accept natural-language instructions, which creates attack patterns such as prompt injection, indirect prompt injection, data exfiltration attempts, unsafe tool requests, and manipulation through retrieved content. These risks cannot be eliminated by asking the model to “ignore malicious instructions.”

Generative AI and large language models should be distinguished conceptually because the surrounding application determines much of the risk. A base model may have no access to company systems, while an enterprise assistant connected to email, documents, and ticketing tools can create significant authorization consequences.

Output handling also needs controls. Generated code, SQL, commands, or business decisions should be validated before execution. Applications should encode deterministic constraints around high-impact actions rather than rely on the model to remember a policy in every conversation.

Guardrails are layered controls, not a single content filter

Organizations often describe guardrails as moderation, but enterprise controls include input validation, system prompts, retrieval permissions, output validation, rate limits, tool allowlists, transaction limits, human approval, monitoring, and policy enforcement outside the model. Each control addresses a different failure mode.

Enterprise GenAI guardrails need more than content filters because a response can be polite and still be unauthorized, inaccurate, or operationally dangerous. A model that reveals payroll data is a security failure even if the content is not toxic.

Control design should consider bypass and degradation. An output classifier may fail on another language, encoding, or novel attack. A human-approval step may become meaningless if reviewers receive too many low-value prompts. Defense in depth assumes individual controls will sometimes fail and reduces the consequence when they do.

AI agents make identity and authorization part of model architecture

An AI system becomes more consequential when it can call tools, modify records, send messages, run code, or trigger workflows. Agent security therefore depends on the identity under which actions execute and the permissions attached to that identity.

Identity and permissions are part of agent design. A shared service account with broad privileges can turn a prompt-injection defect into an enterprise-wide incident. Safer designs preserve user context where possible, use least-privilege tool permissions, require step-up approval for sensitive actions, and separate read access from write capability.

Tool descriptions and schemas should also be treated as security boundaries. The agent should know exactly which operations are allowed and which parameters are constrained. High-impact tools can require deterministic policy checks before execution regardless of what the model proposes.

Testing needs adversarial cases that reflect realistic system behavior

Accuracy testing alone is insufficient for security. Teams should evaluate prompt injection, sensitive-data leakage, privilege escalation, malicious retrieval content, model refusal behavior, unsafe tool calls, hallucinated references, and attempts to manipulate system instructions. Tests should include combinations of failures because real attacks do not respect component boundaries.

GenAI testing needs adversarial cases that target the application as deployed. A model may perform safely in a standalone benchmark but fail when connected to a particular retrieval store or tool. Red-team findings should feed engineering work and regression suites rather than remain as one-time reports.

Versioning is important because model updates, prompt changes, retrieval changes, and tool additions can alter behavior. Security teams should know which combination was tested and detect when production drifts away from that configuration.

Monitoring should include retrieval and tool activity, not only model responses

Traditional application logs often record requests and errors, but an AI application may perform several hidden steps: retrieve documents, call external APIs, invoke tools, retry, and generate intermediate plans. Investigations need visibility into those actions if the organization is to understand what happened.

GenAI observability should include retrieval and tool calls. Security monitoring can look for unusual data access, repeated blocked actions, abnormal token or transaction use, changes in tool-call patterns, and attempts to access resources outside expected scope.

Privacy and retention need equal attention. Logging every prompt indefinitely may create a new repository of sensitive data. Teams should collect evidence necessary for operations and security, apply access controls and retention limits, and avoid treating observability as permission to store everything.

CSPAI preparation should connect risk frameworks with an actual AI architecture

Use NIST, ISO, and other governance frameworks to organize risk, but practice applying them to a concrete system. Draw a generative AI application that includes users, identity, a model API, retrieval, internal documents, tools, and monitoring. Mark trust boundaries and identify controls for confidentiality, integrity, availability, misuse, safety, and accountability.

Then run threat scenarios through the architecture. Ask what happens if retrieved content contains malicious instructions, a user requests data beyond authorization, an agent tries an unapproved action, a model version changes behavior, or monitoring fails. Decide where a preventive, detective, or recovery control should exist.

Ethical and fairness concerns belong in the same governance conversation. Fair and ethical AI requires attention to data representation, decision impact, transparency, and recourse. CSPAI preparation is strongest when candidates can protect the technical system while also explaining how security, privacy, safety, and governance reinforce one another.

Supply-chain risk deserves separate attention because most organizations do not train every model themselves. They consume foundation models, open-source components, embedding services, vector databases, orchestration libraries, hosted APIs, and specialized agents. Security review should identify which provider can change behavior, which component receives sensitive data, how updates are communicated, and what fallback exists if a service becomes unavailable or unacceptable.

Model lifecycle controls should define who can approve a new model or version for production. A newer model may improve benchmark performance while changing refusal behavior, data residency, logging, tool-use semantics, or cost. Teams need repeatable evaluation and rollback criteria so “upgrade to the latest model” is not treated as a routine dependency update.

Incident response for AI should include AI-specific evidence. Responders may need prompts, retrieved documents, tool-call traces, model/version identifiers, policy decisions, user identity, and downstream transaction records. Traditional endpoint or network telemetry may show that an API request occurred without explaining why the AI application made it or what information influenced the action.

Threat models should be revisited whenever the AI system gains a new data source, tool, model provider, or autonomous capability, because each addition can create a new path from untrusted input to privileged action.