This lesson starts with something most security and IT teams now run into regularly. A risk review begins and someone mentions an AI assistant that customer support has been using for weeks, paid on a corporate card, with no ticket, no vendor review, and no clear record of what data went into it. The problem to solve is practical. Keep delivery moving while we regain control of identity, authorization, and visibility for AI use across the organization.
In this course, we will treat AI systems like the rest of our production environment. Every AI feature and every AI tool creates identities, permissions, and data paths that need to be intentionally designed and continuously checked. The outcome we want is not a ban list. The outcome is a mapped access surface we can defend, and a way to convert shadow usage into a safer, supported option.
The risk is rarely the first prompt. The risk is the chain of small decisions that quietly becomes a live access path, such as copy pasting internal text into an external chat, adding a browser extension with broad permissions, or connecting an AI tool to email and ticketing. Once those steps exist, sensitive data can move outside expected boundaries, and the organization may not be able to answer basic questions during an incident or audit about who accessed what and why.
We will use a simple mental model throughout the course. An AI capability becomes an access risk when it creates a new identity, a new authorization decision, or a new route to a sensitive data store without the same controls we require elsewhere. In the next view, track each handoff where a person, app, agent, or connector gains a new way to act on data or systems. Let’s walk the discovery to exposure chain end to end.
Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
To control AI access, we first need a shared map of what exists. An AI access surface inventory is a list and system map of the components that can make requests, receive data, or take actions in our environment through AI features. It includes sanctioned systems we built, third party copilots we enabled, and the shadow tools people adopted to meet real deadlines. If it is not in the inventory, it is easy to over-permission, impossible to review, and hard to investigate later.
When we map an AI enabled workflow, we are looking for a few repeatable component types. We will keep using these same categories in later lessons when we scope least privilege and set up monitoring. This is the system map we will practice with next. Click through and notice where identity is established and where permissions are applied.