PracticalX Toolkit — Day 13 · The Flashlight Problem

What this toolkit is: The opening entry in Arc 3 — AI and Security. Not a technical deep-dive, but the leadership framing every CIO and technology leader needs before deploying AI agents into an environment with existing security debt. Three sections. One clear first move.

Arc 2 covered the people problem — resistance, culture, strategy ownership. Day 12 ended with the financial case for investing now rather than waiting. Arc 3 starts with the reason speed without preparation is dangerous: AI agents don't operate in isolation. They operate inside your environment. And your environment already has cracks in it.

💡

Section 1 of 3

The Threat Model Has Shifted

Most security conversations about AI focus on the AI tool itself — the model, the vendor, the data policy. That is the wrong place to look first. The more important question is what the AI tool can reach. An agent with access to your internal systems, APIs, and credentials doesn't introduce new attack surface. It inherits yours.

The attack surface isn't the AI tool. It's everything the AI tool can touch.

Three shifts that change the calculus

AI agents operate with credentials, make API calls, and traverse networks

Unlike a passive chatbot that generates text for a human to review, an agentic AI acts. It authenticates, reads, writes, calls services, and executes instructions — sometimes with the same access privileges as the engineer who deployed it. Every misconfiguration in your environment is now reachable by software that moves faster than any human operator.

Attacker use of AI is already outpacing defender adoption

Attackers have no procurement process, no change management, no compliance review. They adopted AI for reconnaissance, phishing, and vulnerability scanning the moment the tools became capable enough. The asymmetry is real: defenders move slowly by design; attackers move as fast as the technology allows. The gap is already open.

The flashlight effect

AI doesn't create the vulnerabilities — it finds them faster than anyone has before. Overpermissioned service accounts, forgotten API keys, undocumented integrations — these existed before any AI agent touched your environment. AI is the flashlight. The mess was already there. The question is whether you find it first, or whether someone else does.

🔍

Section 2 of 3

The Three Cracks AI Will Find First

You don't need to anticipate every attack vector. You need to close the three that are most likely to be exploited when an AI agent starts operating inside your environment. These aren't theoretical — they're the patterns that show up in incident reports, post-mortems, and red team findings across almost every organisation that has started this conversation too late.

Where the cracks are

Overpermissioned identities — human and non-human

Service accounts accumulate permissions over time. A script written three years ago was given broad access to get something working — and that access was never reviewed again. Human accounts that changed roles still carry permissions from their previous responsibilities. When an AI agent authenticates with any of these identities, it inherits everything those identities can do. The blast radius of a compromised agent scales directly with how permissioned the identity it operates under happens to be.

Undocumented integrations and shadow IT

Every organisation has integrations nobody planned for — a spreadsheet pulling from an API, a workflow tool connected to the CRM, a third-party service that one team quietly adopted two years ago. These connections are rarely governed, rarely reviewed, and often forgotten. An AI agent traversing your environment will find them. So will an attacker who compromises the agent. The risk is not just what you deployed — it's what you didn't document.

Stale credentials and forgotten API keys

API keys in environment variables, credentials committed to repositories years ago, tokens in config files that were never rotated — this is the most consistent finding in security audits. These keys often have broad permissions because they were created when least-privilege wasn't a cultural priority. They're also the easiest attack path for any automated system — human or AI — that gains a foothold in your environment.

⚠️

The honest question

If a well-resourced attacker had read access to everything your AI agent can reach today — what would they find? Most technology leaders can't answer this question with confidence. That gap is the work Arc 3 is designed to start.

🔵

Section 3 of 3

The CIO's First Move

This isn't about stopping AI adoption — the business case for moving is strong and the case for waiting gets weaker every quarter. This is about ensuring that when your first AI agent starts operating in production, it does so inside an environment that has been prepared to receive it. Three moves. In order. Before you deploy.

Three moves before you deploy an AI agent

Run a permissions audit on every service account the agent will use

Before deploying AI agents, audit every service account in scope. Strip permissions to the minimum required for the agent's intended task. If the agent needs to read from one database table, it should not have write access to the database, access to adjacent systems, or permissions inherited from a broader service account. This is not a one-time activity — it's the beginning of a discipline around non-human identity management that AI makes non-negotiable.

Map what your AI can reach — treat it like an insider threat scope exercise

Run the same mental model you would use for an insider threat exercise: if a malicious or compromised employee had the same access as your AI agent, what could they reach, read, modify, or exfiltrate? Document it. Make it visible to your security leadership. The exercise consistently surfaces integrations and access paths that nobody in the organisation knew still existed. That discovery is the point.

Define a blast radius policy before you need it

Before the agent goes live, answer one question in writing: what is the maximum damage this agent can cause if it is fully compromised? That answer defines your blast radius. Your deployment architecture, access controls, and monitoring strategy should all be calibrated against it. If the blast radius is unacceptably large, reduce the agent's access scope until it is not. Do this before deployment — not after an incident makes the conversation unavoidable.

These three moves are sequenced deliberately. The permissions audit tells you what access exists. The scope mapping tells you what that access can reach. The blast radius policy tells you whether the risk is acceptable. Each step informs the next. Skipping to deployment without them is not moving fast — it's deferring the cost.

📌

Where Arc 3 Goes From Here

The Part Nobody Wants to Talk About

The next five days in Arc 3 get progressively more specific: from the data exposure implications of AI agents, to shadow AI already operating in your organisation, to the architectural patterns that make AI systems defensible by design. Today's toolkit is the framing. The rest of the arc is the detail.

Security debt was always expensive. AI just moved up the due date.

⚠️

A Note on Using This Toolkit

The insider threat exercise in Section 3 is a thought exercise for security planning — not a penetration test. Conduct actual technical assessments through your security team or a qualified third party.
If the permissions audit or scope mapping surfaces a live vulnerability, treat it as a security finding and escalate through your standard incident or risk process immediately.
The blast radius policy document will likely be sensitive — store and share it according to your organisation's information classification standards.

Resources Worth Exploring

Search "OWASP LLM Top 10" — the definitive reference list for AI-specific security risks, maintained and updated as the threat landscape evolves
Search "non-human identity security" — a fast-growing discipline covering service accounts, API keys, and machine identities; directly relevant to AI agent deployments
Search "least privilege principle cloud" — the foundational access control concept that makes blast radius containment possible in practice
Day 14 — Your Data Is the Moat: what happens to your data when AI agents can reach it, and why data governance is now a security conversation

Series Progress

Day 13 / 30