Securing AI, Explained as a Building You Already Know How to Protect

Picture your company as an office tower.

Employees badge in at the front desk. Security knows who is in the building, which floors they can reach, and what they touched. That system took years to build, and most companies are reasonably proud of it.

Then, one afternoon, a thousand new employees show up. They did not go through HR. Nobody issued them a badge. They walked in through the loading dock, the stairwell, a propped-open fire door, because someone on the marketing team found a slick AI tool that summarizes reports in ten seconds and just started using it. Another team connected a coding assistant straight to the production repo over the weekend. A third quietly gave a chatbot its own login to the CRM, because typing the same query twice was annoying.

Nobody in security approved any of it. Nobody in security even knows the extent of it.

This is shadow AI: the AI tools, plugins, and agents employees adopt without going through procurement, security review, or IT. It looks harmless in the moment, an extension here, a free trial there, but each one is an unbadged visitor with a key to some part of the building, and no record of them ever walking in.

A well-run building has exactly one way in for employees who need building-wide access: the front desk. It checks identity, issues a badge scoped to a specific floor, and logs the entry. Nobody gets to skip that desk just because they are in a hurry.

The equivalent for AI agents is what is now called an agentic gateway: a control point that sits between every agent and everything that agent is allowed to touch, whether that is a database, an API, a file store, or another agent. Instead of agents connecting directly to production systems with whatever credentials they were handed, they pass through a single choke point that authenticates the request, checks it against a policy, and logs what happened.

Most companies do not have this yet. What they have is closer to a building where half the doors were fitted with badge readers, and the other half were never touched because nobody thought agents would need their own doors at all.

A gateway does not make an agent trustworthy. It makes the agent’s behavior visible and constrainable, which is the precondition for trusting it at all.

Here is where it gets worse. Even where badges exist, they were often issued in a panic, and panic tends to produce master keys.

An agent that needs to read three spreadsheets is instead granted access to the entire finance drive, because scoping permissions precisely takes longer than clicking allow all. A support bot that only needs to look up order status is quietly handed write access to the customer database, because the two permissions came bundled together and nobody split them apart. A coding assistant that should only touch a staging branch is connected with credentials that also reach production, because that is the token that was lying around.

This is over-permissioning, and with AI agents it is more dangerous than with a human employee for one specific reason. A human with a master key still has judgment, hesitation, a sense that some doors should not be opened. An over-permissioned agent has none of that. It will use every key on the ring the instant a prompt, a poisoned document, or a manipulated instruction tells it to, and it will do so at machine speed, across every floor its key opens, before anyone notices the elevator moving.

The fix is unglamorous: scope every agent to the minimum floor it needs, issue short-lived badges instead of permanent ones, and require a fresh check every time it tries a door it has not opened before. None of that is new security thinking. It is the same least-privilege principle security teams have preached for identity and access management for two decades. Agents just make the cost of skipping it much higher, because they act continuously and at scale.

Most buildings do have cameras. The problem is what they are pointed at.

Telemetry, for AI systems, means logging: which agent made which request, which documents it read, which tools it called, what it was told to do, and what it actually did. Done well, this is the security camera footage and the badge-swipe log combined, the record that lets you answer what happened instead of guessing.

Done poorly, and this is the common case, telemetry gets collected for the wrong reason. Teams log agent activity to measure usage, cost, and latency: how many tokens burned, how many calls made, how fast the response came back. That is real monitoring, but it is monitoring aimed at the lobby foot-traffic counter, not the hallway cameras. It tells you the building is busy. It does not tell you that visitor 4,417 walked into the server room at 2 a.m. and copied a filing cabinet.

Security-grade telemetry for agents needs to answer different questions than performance telemetry does. Not just did it respond fast, but which documents fed into that response, whether any of them were untrusted, what tools the agent decided to call and why, and whether the chain of actions matches what a legitimate request should look like. Without that thread, an incident after the fact is a locked door with no idea who has the key or when they used it.

Once the gateway exists, permissions are scoped, and the cameras face the right direction, you still need someone watching the monitors.

Protection is the badge reader itself: policies enforced at the gateway that stop an agent from reaching a floor it has no business on, rate limits that stop it from trying every door on a floor in ten seconds, and input handling that treats every retrieved document, email, or web page the agent reads as a potential set of instructions in disguise rather than as inert data.

Detection is the guard reviewing the footage: watching for an agent that suddenly requests a floor it has never asked for before, a request pattern that matches a known trick for smuggling instructions inside content, or an action that is individually normal but, chained with three others in sixty seconds, adds up to a break-in. Most of the real damage in agent-based incidents does not come from one dramatic door being kicked down. It comes from an agent doing five individually reasonable things in a row that nobody was watching for as a sequence.

Neither replaces the other. A lock without a guard eventually gets defeated by someone patient. A guard without a lock is just watching the theft happen in real time.

Which brings us to a distinction people routinely blur.

Security for AI is everything above: gateways, scoped permissions, telemetry, detection, applied to protect the AI systems themselves and the building they operate in. It is the discipline of treating agents as a new class of building occupant that needs its own badges, its own cameras, and its own rules.

AI for security is the opposite direction: using AI to staff the guard station. Instead of a person squinting at twelve camera feeds, a system that watches all twelve at once, flags the one frame that looks wrong, and surfaces it to a human before the door closes behind whoever walked through it. Used well, this is a genuine force multiplier, catching patterns a tired analyst at 3 a.m. would miss.

Used carelessly, it is the same building with a new problem: now one of your guards is also an agent, with its own badge, its own permissions, and its own blind spots. If that guard was over-permissioned or never went through the front desk itself, you have not added security. You have added another unbadged visitor, one who happens to be holding a clipboard that says Security on it.

The two disciplines need each other, but neither one is a substitute for the other. AI for security does not work if the building underneath it, the agents, the gateways, the permissions, was never secured in the first place. Security for AI does not scale if every alert still requires a human to review every camera feed by hand.