Security Controls in an AI Era: An InfoSec Guide | Vistrada

• Security controls are safeguards that protect information and systems from unauthorized access, changes and disruption.
• Existing controls remain relevant for AI, but their coverage must be verified across data retrieval, connected identities and downstream actions.
• Authorization must operate independently of model outputs, with human approval reserved for consequential actions that warrant oversight.
• Workflow testing, correlated system evidence and tested recovery procedures help establish whether safeguards work.
• Remediation should prioritize business impact, assign accountable owners and verify that changes resolve the identified gaps.

An AI assistant that drafts customer replies may already have passed your organization's security review. But what happens when the business wants it to start sending those replies or updating customer records? The software may be the same, but the authority surrounding it has changed.

A 2026 Cloud Security Alliance study found that 53% of surveyed organizations reported AI agents exceeding their intended permissions. This raises concerns about how organizations manage access as AI applications take on more responsibility.

Approving an AI product doesn't automatically authorize every new connection or action. Security teams need to understand what these applications can access, which permissions they use and whether existing controls can prevent unauthorized activity.

What Changes, and What Doesn't, About Security Controls for AI

Security controls help organizations protect sensitive information, manage access and respond when something goes wrong. That responsibility hasn't changed with AI. Businesses still need to keep data confidential, prevent unauthorized changes, maintain system availability and monitor for suspicious activity. What matters now is whether those protections still work when AI applications access information and interact with other systems.

The difference lies in how information moves and who, or what, can initiate actions. An AI assistant may retrieve records from several systems, combine the information into a response and propose changes through connected applications. Each connection introduces permissions and data flows that existing controls may not fully cover. A control that works for direct employee access may require changes when an application retrieves information or acts on an employee's behalf.

Connecting an AI assistant to customer records introduces a potential gap between the employee's permissions and the permissions used by the application. An employee may only be authorized to access their assigned accounts, while the assistant's connector has access to a much larger dataset. The organization needs to ensure those broader permissions cannot be used to bypass employee-level restrictions. Logs should also identify who requested the information, which credentials were used and whether the downstream system allowed the request.

The NIST security control catalog provides a foundation for selecting and tailoring administrative, technical and physical safeguards. Preventive, detective and corrective controls all remain relevant. The task is to determine whether their implementation still protects the complete workflow, rather than assuming an existing security feature provides sufficient coverage.

Assess AI Exposure Before Choosing Controls

Two AI assistants might look almost identical to employees, yet introduce very different security concerns. One might send information to an external provider, another could search internal documents, while a third might update customer records directly. Each arrangement brings different questions about who can access information, where that information goes and what the application can do with it. The more authority an application has, the more important it becomes to understand how that authority is controlled.

These differences reflect how the applications operate, not a progression from basic to advanced AI. A useful assessment should establish what information each application receives or retrieves, which systems and tools it can reach, whose credentials it uses and what operations those credentials permit. It should also identify whether downstream systems independently authorize requests and whether unwanted actions can be contained or reversed.

A customer support assistant that retrieves records and drafts responses operates within relatively narrow permissions. Giving it the ability to send messages and modify tickets expands its operational authority and introduces new authorization requirements. Before enabling those features, the security team needs to establish what the assistant can change, which systems will process its requests and whose permissions those systems will rely on. The business also needs to decide which actions require approval and which can proceed automatically.

This assessment should complement shadow AI discovery, which helps identify applications already in use. Once a workflow is known, the more important control question becomes whether its actual access and authority are appropriate for the business activity it performs.

Decide Which Existing Controls to Retain, Adapt or Add

Introducing AI does not necessarily require an entirely new security control environment. Existing identity management, data protection, monitoring and incident response capabilities may already address much of the exposure. The challenge is determining whether those safeguards operate across every relevant component of the AI workflow.

The following comparison provides a practical basis for deciding what to retain, where existing coverage needs adapting and when an additional control is justified.

Two familiar controls illustrate why this review matters. Single sign-on can authenticate an employee without ensuring that every connector respects that employee's access restrictions. Likewise, data loss prevention may inspect browser uploads while leaving other paths, such as document retrieval, APIs or tool calls, outside its coverage. Actual protection depends on the architecture and configuration.

Secure configuration, patching, dependency reviews and applicable physical safeguards also remain necessary. The decision to retain, adapt or add a control should follow evidence of its effectiveness, rather than whether the organization already owns a product offering the relevant feature.

Put Enforceable Boundaries Around AI Outputs and Actions

An assistant receives information from several sources, including application instructions, user requests and external content. The problem arises when information intended to support a task influences what the assistant believes it should do.

Suppose the customer support assistant retrieves a ticket containing instructions to ignore its assigned task, access another customer's records and send the information to an external address. The ticket is business data, and its contents should have no authority to change the application's operating rules. However, a language model may interpret malicious content as instructions and produce an unauthorized response or proposed action.

Prompt injection becomes a concern whenever an AI application processes information it cannot fully trust. The instructions might come from a retrieved document, a website or another source the model encounters while completing a task. How much damage they can cause depends on what the application can access or do. System prompts, filters and retrieval restrictions can help, but they cannot reliably prevent every attempt to manipulate the model. Security-sensitive decisions therefore need controls that operate independently of the model's interpretation.

Enforce Authorization Where Actions Actually Occur

Consider what happens when the support assistant proposes updating a customer ticket. The model produces a suggested action, the application decides whether to invoke an available function, and a connector submits the request using an authorized identity. The destination system then determines whether that identity can perform the requested operation.

This sequence matters because the model itself does not inherently possess the connector's permissions. The surrounding application determines which functions are available, which credentials execute them and whether the proposed operation proceeds.

An assistant could make the right decision about updating a ticket but apply that change to the wrong customer's record. If the employee doesn't have permission to modify that account, the request should be blocked before anything changes. The destination system should also enforce its own access rules, rather than relying entirely on the AI application to get them right. This gives the organization another opportunity to stop an unauthorized action.

OWASP identifies excessive permissions and insufficient restrictions on autonomous operations as contributors to excessive agency risks. These risks also explain why validating a model's output format is insufficient. A request can satisfy every required field while still targeting the wrong record or requesting an inappropriate business action.

Use Human Approval Where It Adds Meaningful Oversight

Human review can provide another safeguard when an action has significant financial, operational or customer consequences. For instance, allowing an assistant to suggest a customer reply introduces less authority than permitting it to transmit that message. Sending the reply may warrant approval, depending on the information involved and the consequences of an error.

That approval must give reviewers enough context to make a useful decision. Employees need to see what the assistant proposes, which record it affects and the implications of proceeding. When every routine operation produces another approval request, reviewers may begin accepting them without meaningful scrutiny.

Not every action needs someone to sign off on it. Routine tasks can proceed automatically as long as they stay within the permissions already established for the application. Actions that could expose sensitive information, change important records or have wider business consequences deserve closer review. Even then, human approval shouldn't be the only safeguard. The system still needs to check whether the action is authorized.

Test Whether the Controls Work in the Real Workflow

A security control can look perfectly adequate on paper and still fail when someone puts it to the test. That's why checking configurations alone isn't enough. Security teams need to see how the application behaves when employees use it correctly, when requests fall outside their permissions and when something goes wrong.

Take the customer support assistant. An employee should be able to retrieve the records they're authorized to view and generate a suitable draft reply. Once that works, the next step is to find out whether the assistant respects the limits placed on it.

Useful tests include:

• Unauthorized access: Request customer records outside the employee's assigned accounts and check that the request is denied.
• Manipulated content: Add malicious instructions to a support record and see whether the assistant attempts to follow them or request additional permissions.
• Restricted actions: Attempt to modify records or use functions the assistant hasn't been authorized to access.
• Access revocation: Disable a connector or revoke its credentials, then check whether existing sessions or subsequent requests can still access the system.

Document what each test was supposed to demonstrate, what actually happened and who is responsible for fixing any problems. If revoking access doesn't take effect immediately, establish how long the credentials remain usable and whether that delay creates additional exposure.

Evidence should come from the systems involved, not just the assistant's activity logs. A record showing that the assistant requested an action doesn't tell you whether the destination system carried it out. Identity records, connector logs and downstream application events provide a more complete picture.

Keep enough detail to investigate incidents without collecting unnecessary customer information or sensitive prompts. Tests also need revisiting when permissions, connectors, models or workflows change, since previous results may no longer reflect how the application operates.

Prioritize Control Gaps Your Team Can Own and Resolve

A control assessment becomes useful when it helps the organization decide what to restrict, remediate or accept. Prioritization should consider the sensitivity and reach of accessible information, the authority granted to the application, plausible business consequences and any failures observed during testing.

Not every security gap carries the same level of risk. An assistant that retrieves sensitive documents without authorization can cause immediate harm, just as one that changes customer records without authorization can. The urgency depends on the information involved, the scope of access and the likely business consequences. In either case, it may be necessary to disable certain functions or reduce permissions while the team investigates. Once the immediate exposure is contained, the focus can shift to fixing the problem properly.

That might mean adjusting connector permissions, changing how the application handles requests or adding authorization checks. Whatever the solution, someone needs to own the work, confirm that the changes are effective and decide whether any remaining risk is acceptable.

Progress measures should also reflect what the team is trying to protect. Tracking unresolved high-impact gaps, the proportion of consequential action boundaries tested and completed response exercises gives leadership more useful information than a general AI security score.

Some control gaps can be addressed by the IT and security teams already in place. Others need input from business owners, particularly when decisions involve what an AI application should be allowed to access or change. More complex issues may require specialist support to design and test the right safeguards. Understanding who needs to be involved helps organizations direct their resources where they're most useful, while keeping responsibility for business risk with the people who own the workflow.

Build Confidence in the Controls You Can Verify

Approving an AI product is only part of the process. As employees connect it to more systems or give it permission to perform additional tasks, the security team needs to assess whether the existing controls still provide enough protection. That means understanding what the application can access, what actions it can take and whether the safeguards work when tested.

Start with one consequential workflow and examine its data access, executing identities, action permissions and recovery procedures. This should reveal which existing controls remain effective and where additional work is necessary.

When internal capacity or specialist expertise is limited, Vistrada's vCISO team can support security assessments, policy development, remediation planning and ongoing program operations. Discuss your AI-related control gaps and remediation priorities with Vistrada.