See how a global enterprise uncovered real AI use, governed employee adoption, and extended its existing security architecture to protect the applications, models and agents coming next.
A global defense and mission-support company with about 20,000 users was defining how AI should be used across the business. Security leaders were cautious about the risks, while the business wanted a path to benefit from AI.
We helped the customer establish what AI was already in use and design a security model that could govern employee adoption while protecting the applications, models and agents the business planned to build or deploy next.
The organization was still deciding what role AI should play in the business. Security leaders were cautious about formally sanctioning its use and believed AI remained limited enough to restrict if necessary.
That confidence was based on assumption rather than evidence. Employee behavior had already moved ahead of the decision. Before the organization could determine what to allow, restrict or govern more closely, it needed evidence of what was actually happening across the environment.
Employees were already using third-party AI services before the organization had formally decided what should be sanctioned. AI adoption was therefore developing outside the governance model security was still trying to define.
Leadership believed AI access could be restricted if necessary. However, the security team lacked the visibility to know which services were in use, how widespread adoption had become and where the greatest exposure sat.
A blanket block was not a viable strategy. The business wanted employees to benefit from AI, but security needed a way to distinguish legitimate use from services and behaviors that introduced unacceptable risk.
The customer’s workforce of about 20,000 users did not operate through a single access model. Knowledge workers had full mobile-user access, while roughly half of the workforce consisted of frontline employees who primarily needed access to a limited set of browser-based business applications.
AI adoption had already outrun policy, while the next generation of business AI was still being designed. The customer needed a security model capable of governing both.
We had already designed and deployed the customer’s managed SASE environment, giving us an established security architecture to build on rather than introducing a separate AI security stack.
From there, we mapped the controls needed across AI discovery, application policy, data protection, browser activity and runtime security. We reused existing technology where it could meet the requirement and introduced additional controls where the customer’s current or planned AI use created a gap.
The result was a connected architecture capable of governing the AI employees were already using while extending protection to the applications, models and agents the customer planned to build or deploy.
The customer already had Prisma Access in place but had not yet used its existing visibility to understand AI activity across the environment. We used that capability to identify the AI services employees were already accessing and establish the baseline for the wider architecture.
From there, we incorporated AI Access Security through Prisma Access to classify AI services as sanctioned, tolerated or unsanctioned and apply policy accordingly. DLP and CASB controls protected sensitive data and allowed higher-risk activity to be restricted without broadly blocking legitimate AI use.
While the two workforce groups retained different access models, Prisma Browser provided a common control layer for browser-based AI activity across both frontline employees and knowledge workers, including users who already had the Prisma Access agent installed.
The browser also provides deeper visibility into AI interactions, including prompt activity where enabled, helping the security team understand how approved AI services were being used and refine controls as usage evolved.
We extended AI controls beyond browser-based activity to applications running locally on employee devices.
AI Access Security, delivered through Prisma Access, provided visibility and protection for applications communicating with internal or external AI services, models and agents.
We designed the architecture to cover the AI applications, models and agents the customer planned to build or deploy, not just the AI employees were already using. The design included AI agent discovery and assessment, giving the security team a way to inventory and assess agents as they were introduced.
Prisma AIRS extended protection into those future AI environments through model security, prompt injection protection and AI red teaming to identify weaknesses before and after applications moved into production.
The customer’s cyber insurance requirements called for a defined incident response capability, so the design had to address more than prevention and policy enforcement.
We incorporated a 12-month Unit 42 incident response retainer into the wider security strategy, giving the organization a defined path to specialist support if an AI-related security incident occurred. The relationship also connected the security team to ongoing research into emerging AI threats and attack techniques as the risk landscape evolved.
A good security design is only useful if the customer can operate and evolve it. We went beyond defining technical controls, helping the customer validate real AI behaviour, adapt its existing architecture and build an approach that could evolve as adoption grew.
Rather than telling the CISO that shadow AI could be a risk, we showed where AI use was already happening across the organization.
The evidence moved the conversation from assumed control to verified behavior, giving the security team a factual basis for deciding what should be allowed, restricted and governed more closely.
Our role did not begin with the AI project. Having already designed and deployed the customer’s SASE environment, we could extend that architecture with AI-specific controls rather than introduce a disconnected security model.
We maintain the customer’s as-built SASE architecture as it evolves, with AI security now incorporated into the same design. This keeps access, data protection, browser controls and AI security documented as part of one connected architecture rather than as separate environments.
Prisma Browser was designed as the enterprise browser standard across the customer’s workforce. When the standard licensing structure did not align with the customer’s phased rollout, we challenged it and worked with Palo Alto Networks to create a more practical commercial model.
That allowed the customer to start with the licenses and services needed immediately, then bring the remaining licenses online as adoption expanded.
The customer did not need to become an expert in every emerging AI technology before it could make good security decisions. We brought specialist AI, security and architecture expertise into the relationship, helping the internal team understand the risks, evaluate new requirements and make informed decisions as AI adoption evolved.
As the tools continue to surface new visibility into AI use, we help the customer translate those findings into practical policy and architecture decisions, including where new controls should be introduced.
The internal team retains ownership of the decision-making process, building the context and capability to govern its own AI environment rather than becoming dependent on an external provider to interpret every new requirement.
AI security starts before the next AI project goes live. We help organizations uncover the AI already in use, design controls around how employees and data interact with it, and secure the applications, models and agents they plan to deploy next.
If your AI strategy is moving faster than your ability to see and control it, let’s talk.
globalgig.com
