AI security for businesses: a practical 90-day roadmap.

Start with the business workflow

An employee asks an assistant to summarize a proposal. A support team connects a chatbot to customer records. A developer gives an agent permission to update a repository. Each use can save time, but each creates a different security question. What information reaches the model? Whose access does it use? What happens if it follows an instruction the business never intended? A useful AI security program starts with those questions and follows the work all the way to the resulting action.

This guide is for business leaders, technology owners, and security teams adopting AI without unlimited time or staff. The goal for the next quarter is a defensible operating baseline: a known set of systems, named owners, clear limits, and evidence that important controls work. The 90-day sequence below is our suggested planning structure. It is not a standard, a fixed delivery promise, or a claim that every AI risk can be resolved in one quarter.

NIST’s AI Risk Management Framework organizes work around Govern, Map, Measure, and Manage. Those functions are iterative, with governance throughout, rather than a one-time checklist. [1] For your organization, that means a deployment decision should come with a responsible owner and a way to revisit it as the system changes. This article focuses on cybersecurity; reliability, privacy, and the effects of consequential automated decisions also need appropriate review.

Inventory the AI you actually use

Start with a working list of AI use cases, including features inside software you already buy. Ask department owners to show a normal task from beginning to end. Compare those conversations with approved applications, procurement records, and available sign-in information. Record the purpose, business owner, technical owner, provider, users, connected data, and available actions. Include pilots and developer tools. A product name alone is too coarse: the same assistant may be low exposure in one department and highly consequential in another.

Prioritize by the consequence of a mistake or misuse. An assistant drafting copy from public material warrants a different review from one reading confidential proposals or changing customer accounts. Ask whether the workflow reaches sensitive data, serves external users, can make changes, or supports a decision someone cannot easily undo. Record the reason for the priority. This gives leadership a choice it can discuss, rather than a colored score with no explanation.

For purchased services, collect the terms and settings that apply to your actual subscription and feature. Ask about training use, retention, deletion, connected providers, and incident support. NIST’s Generative AI Profile calls for supplier review, documented responsibilities, and contracts addressing the use and protection of organizational content. [6] Put unanswered questions in the risk register with an owner and review date. A sales statement should become a verified term or configuration before you rely on it.

Understand how prompt injection becomes business risk

Prompt injection occurs when input redirects a model’s behavior in an unintended way. It can come directly from a user or indirectly through something the system reads, such as a document or web page. OWASP emphasizes that retrieval and fine-tuning do not eliminate this problem. The business impact depends on what information and capabilities the application exposes to the model. [2]

Consider a fictional equipment supplier using an assistant to prepare renewal summaries. It reads customer attachments, searches contract records, and drafts a response for an account manager. A malicious attachment includes instructions to include another customer’s discount schedule. The critical questions are concrete: can the search retrieve that schedule under this user’s identity, can the draft reveal it, and can the assistant send anything without review? The attachment is an entry point; the connected workflow determines the possible damage.

Draw that path with the people who own the application. Mark where outside content enters, where protected data becomes available, and where a recommendation becomes an action. Prompts and filters can reduce exposure, but OWASP does not present them as foolproof prevention. [2] Your design discussion should identify the control at each connection and the person who can change it. That drawing also becomes a useful starting point for a focused security test.

Protect data before it reaches the answer

Retrieval-augmented generation, usually shortened to RAG, supplies a model with content retrieved from other sources to help answer a request. Connecting company documents does not automatically preserve the access rules of the original repository. OWASP identifies unauthorized retrieval and information crossing between users or groups as risks, and recommends permission-aware access controls and separation of datasets. [3] Treat the search layer as part of your security design.

For the fictional supplier, create two test users with different account assignments and plant distinctive, synthetic pricing records. Check whether each user can retrieve only the permitted records, including through summaries, citations, and follow-up questions. Change an account assignment and repeat the checks. This turns “the assistant respects permissions” into a specific, observable result. Agree how quickly permission changes must take effect before choosing the implementation.

Document which copies of a record exist: the source, search index, conversation history, cached answer, and operational logs. Decide what each copy needs to retain and how removal will be verified. A useful review includes the document owner who understands the information and the engineer who understands its movement. If nobody can explain how a revoked permission reaches the retrieval layer, record that as an unresolved design question before expanding the rollout.

Put limits around what an AI agent can do

An AI agent adds actions to the workflow. It might create a ticket, change a record, or send a message. OWASP describes excessive agency as unnecessary functionality, permissions, or autonomy. Its guidance includes narrowing tools and enforcing authorization in the systems that execute requests. [4] Begin with a list of actions the business actually needs, then compare it with the capabilities and credentials available to the agent.

For every action, name the affected resource, the identity used, the permitted scope, and the consequence of a wrong request. In the supplier example, drafting a renewal summary and changing the agreed discount are separate permissions. The account manager may need the first while pricing staff retain the second. Make that distinction visible in the design and in the tool list. A broad connector should not decide the business’s approval policy by default.

For consequential actions, an approval should describe the exact operation, target, and parameters. The execution service should verify that authorization independently; a changed request needs a new approval. OWASP’s agent guidance also calls for protection against approval reuse. [5] Give reviewers a clear preview they can evaluate, and decide who handles requests when the normal approver is unavailable. An approval step needs an operating process as well as a button.

Test the outcome the business needs to prevent

Define test objectives in business terms: one customer must not receive another customer’s records; an attachment must not change an approved recipient; an agent must not execute a restricted change. Include the application around the model in the scope. Sign-in, sessions, APIs, and the identities behind connectors still matter. A test limited to unusual chat prompts leaves those paths unanswered.

Use authorized environments, synthetic records, representative roles, and agreed limits on spending and request volume. Write down permitted targets, excluded dependencies, a pause contact, and how evidence will be handled. For a production-only workflow, agree what can safely be demonstrated and where the test must stop. Report that limit explicitly. A chain demonstrated up to a proposed action is different evidence from an action completed in a controlled test environment.

Ask for reproducible findings with prerequisites, observed effects, affected components, and a correction assigned to an owner. Because model behavior can vary, preserve attempt counts and relevant configuration alongside the result. OWASP recommends structured testing before deployment and after material changes to prompts, tools, retrieval, memory, or providers. [5] Retest the failed path after remediation. A model’s reassuring reply is not sufficient evidence if the underlying tool call still succeeded.

Turn the findings into a 90-day roadmap

Days 1–30: establish the starting point. Name an executive sponsor and a working owner, assemble the inventory, and select the workflows with the greatest consequences for focused review. Capture the data flow and the open vendor questions. Set temporary limits where authority or data handling is unclear. End the phase with an agreed priority list, owners, and a decision about which pilots may proceed under which conditions. Address urgent exposure immediately rather than waiting for the phase to end.

Days 31–60: implement the priority controls. Work through the selected workflows with engineering and business owners, resolve unnecessary access, and define review steps for consequential actions. Turn each correction into an assigned task with a completion check. Prepare test users and safe records, then run an initial assessment of the most important paths. Review progress weekly around decisions and blockers. Buying a control or approving a policy does not close a task until its intended behavior can be demonstrated.

Days 61–90: verify and establish the operating rhythm. Retest corrected findings, rehearse an incident, and record remaining limitations. Assemble a concise evidence package and schedule the next review around releases, new integrations, and material provider changes. Ask leadership to decide on unresolved risks explicitly: fund the next correction, keep a restriction, or accept a documented residual risk with a review date. Adjust the schedule when complexity requires it; a calendar deadline should not silently approve unfinished work.

• By day 30: an inventory, workflow map, priority list, and named decision owners.
• By day 60: implemented controls, a scoped assessment, and assigned remediation tasks.
• By day 90: retest evidence, an exercised response plan, and a dated next-review decision.

Prepare to investigate, contain, and explain an incident

Return to the fictional supplier and assume an account manager finds the wrong customer’s pricing in a draft. Who receives the report? Who can restrict the assistant while normal account work continues? Who determines which records were actually retrieved? Use those questions in a tabletop with business, engineering, security, and the appropriate legal or privacy owners. NIST’s Generative AI Profile recommends assigning incident responsibilities, rehearsing response, and planning fallbacks for third-party AI dependencies. [6]

Keep the evidence needed to reconstruct a consequential action: the relevant actor, retrieved resource references, requested tool operation, authorization outcome, and system version. Protect those records and avoid collecting unnecessary sensitive content. [5] In the exercise, ask participants to locate the evidence rather than assuming it exists. If the provider does not expose a necessary record, decide whether a different configuration, compensating control, or narrower use case is needed.

Give leadership a short operating readout: high-priority workflows reviewed, unresolved findings by owner, remediations verified, and overdue decisions. Include the scope and date so the evidence cannot be mistaken for coverage of every system. Keep the inventory current through procurement and release review. The useful question at the next meeting is whether a new data source, tool, or business use has changed the original decision.

Choose the security engagement that answers your next question

Start with an AI Risk & Gap Assessment when the organization needs an inventory, accountable owners, and a prioritized plan. Choose AI Architecture & Engineering when a workflow is still being designed or the team needs specific changes to permissions, deployment, or data handling. Choose AI Security Testing when you need evidence about what an attacker can achieve in an implemented system. These engagements answer related questions, but the decision you need should determine the scope.

Source Point Security connects that work through principal-led consulting. The same principal scopes, performs, and reports the engagement. Testing produces findings with reproduction evidence, business impact, practical fixes, and a retest of remediated findings. Architecture work produces designs and implementation guidance. Governance work connects responsibilities and evidence to the program. Begin with the workflow causing uncertainty and the deadline driving the decision; that is enough to shape an initial conversation.