Recently I’ve been doing a lot of configuration work to standardize environments. One of the goals of this experiment was to have all of our applications driven by App Configuration instances backed by pass-through Key Vaults, so a developer could pull down a repository and, with the appropriate local and environment permissions, be completely up and running. All the application needed was a connection string to an App Configuration. This would dramatically reduce the spin-up time for a new developer.

One thing I noticed (and kudos to Anthropic and Claude here) was that the AI starts to learn this pattern and take advantage of it. It naturally fills in the appropriate parameters with the App Configuration and Key Vault variables it has access to. And it really made me start to wonder: this agent, acting on my behalf, has complete control over any Key Vault parameter, secret, certificate, or password I personally have access to.

The agent had full access to my identity. And yes, I have standing access to a lot of environments and a lot of parameters. It made me think. Down the road, would I catch a call where the agent had mistakenly gone out and grabbed a production value? Where something got run against a production environment by accident? That, in my mind, was a problem.

The Insight That Reframed It

AI didn’t actually create this new security risk. It just amplified poorly designed security measures that companies might not already have in place. The speed you can do development with an AI agent is what’s highlighting this. A developer with standing production access is a latent risk. A human running an agent with standing production access is a very much active one.

Or maybe you’re troubleshooting a production issue one night. A system is down and people are granting temporary access to users to actually get things up and running. What if the appropriate change-management tickets aren’t documented and the permissions that got put in place aren’t rolled back? Or maybe someone’s using an AI agent to do work against dev and inadvertently it’s now pointed at production. These issues were always problems. We’re just having to think about them now because AI is shortening the fuse.

No amount of prompt engineering will get you to good production security without good awareness. In my mind, the controls have to live outside the tool. External controls should exist. Internal guardrails help, but security patterns should have always been followed, not just in this new AI world.

1. Privileged Identity Management: Stop Holding the Keys

Product teams need to move quickly. Their job is to deliver on unmet product needs and serve what customers want. To do that, people sometimes need access to production environments. They need to troubleshoot issues, look at logs, or mimic situations they can’t duplicate in dev or QA. I believe people do need that access. But it needs to be controlled and audited.

What it shouldn’t be is standing access. That’s just asking for an incident call later because elevated privileges got abused by an AI agent. PIM and just-in-time elevations, paired with auditability, justification, MFA, and approvals where the system warrants them, are where this actually matters. The engineer gets the access they need to troubleshoot the issue, but it’s done in a very controlled environment.

None of this is new. These controls existed long before AI agents went mainstream. Azure has PIM. AWS has IAM role session policies. Google Cloud has workload identity. The behavioral shift we need is this: elevating to those privileged rights has to be a deliberate act the human performs, not a default the agent inherits.

2. Environment Separation as a Hard Boundary

Identity controls are good. Boundaries are even better. Subscription separation is the wall that doesn’t care how clever your prompt is.

For each of your environments, it’s good practice to actually have separate subscriptions, accounts, or projects: dev, QA, staging, and prod. Through the use of security groups and roles, developers and engineers get the access they need to do their jobs in dev and QA while having no standing rights to prod. Not read-only. Zero.

Done this way, an agent can never touch production. It’s not a policy. It’s not a sentence in a prompt. It’s the fact that the resources sit behind a trust boundary the agent can’t violate. When you start talking about blast radius, the worst that can really happen in this structure is that an agent deletes parts of dev or QA, not your production environment, where it would actually cause an incident and customer impact. It stays in the environment it started in.

3. PRs and Branch Policies as the Human Checkpoint

Another area to talk about for AI controls is PR and branch policies: using humans as the gated checkpoint. AI can author code all day, but humans have to approve it and merge it in. The PR is the place that turns “the agent wrote it” into “a person signed off on it.”

This is where proper controls matter: a protected main branch, required reviewers, no self-merge, and CI gates passing. People used to say they didn’t have time to properly set up an appropriate branching structure. AI velocity changes that. You can actually use the agent to bootstrap the process. What used to be “we should” is now “we have to.” We have the time and the tokens to implement this properly.

The reviewer’s job goes further than syntax. They’re validating the intent behind the code. I’ll be the first to say that sometimes I get a little click-happy and don’t give a PR the time it deserves. We have to be careful of these rubber-stamp reviews. The PR is only a valid checkpoint if the human spends the time to actually dive in and approve it appropriately.

4. Secret Management Hygiene

So we set up appropriate PRs and branching, and then good secret management. But what happens when secret management goes wrong?

Agents work with references, not values. If the secret never leaves the vault, the agent never sees it. Even with all the systems above in place, if we don’t actually use them (if we put secrets in code, config, environment files, or chat context), it’s all for nothing. Key Vault and Secrets Manager references only. The runtime resolves. The developer never holds anything.

Expanding on this: short-lived tokens, and token rotation that actually runs on a schedule. AI agents are great at configuration management and infrastructure as code, but secret sprawl is a real risk. Agents are well known for being lazy. They’ll happily inline a connection string or hardcode it into a script to finish the task and move on to the next one. This is where appropriate human visibility at the PR review process is a complete necessity.

5. Network Segmentation and Private Endpoints

Identity is one layer of the onion. Another is the network. Defense in depth means a compromised credential in one environment hits a wall when it tries to reach a different one.

Production Key Vaults, databases, and service buses shouldn’t be publicly accessible. They should only be traversable through private endpoints. Environment segregation, where you don’t allow a development environment to cross-talk with production at the network layer regardless of what credentials are being used, is critical. This protects against an agent mistakenly having one piece of IaC pointed at one environment while other configurations point at another.

The point to reinforce here is that we need to assume each control could fail. The reason these structures are safe is the compensating controls. Agents still can’t route to the resource that matters.

6. Audit Logging and Alerting on AI-Adjacent Actions

Now for one we sometimes forget about, especially in MVP systems: observability is a prerequisite for accountability. If you can’t see what an engineer or an AI touched, you can’t answer for it later when you go to play back a situation.

Everything needs to be logged: reads, writes, role activations, Key Vault accesses, especially across AI-assisted sessions. Modern SIEM tools that search for patterns that don’t fit a human pace are a must. Bulk secret reads. After-hours deployments. Cross-tenant or cross-subscription activity. Elevation and privilege changes that aren’t anticipated. You need to be able to alert on these so they can be flagged for response.

Logs are your only defense when you’re trying to find out what happened between 3:05 PM and 3:09 PM and what an agent actually touched.

7. Infrastructure as Code Review Gates

Now for the one that actually prompted this whole post: AI is phenomenal at infrastructure as code and configuration management. It writes IaC faster than a human reviewer can catch a misconfigured network rule. Policy-as-code is how you keep up.

This is where tools like Azure Policy, Checkov, and tfsec come into play. Just make sure you actually have one of them in place. The point is to block scripts at apply time, not just at review time. If you’re doing this properly, your environment configuration scripts live in a repo. They can be AI-generated (pick your Bicep or Terraform flavor), but they go through the same PR and human review as any other piece of code.

This is how it should be for any IaC code, handwritten or otherwise. The gate shouldn’t care whether a human or an AI wrote it. The same controls should exist either way.

8. Least-Privilege Service Principals for Automation

I’ve worked in environments where services ran with elevated permissions so they could provision new collections and resources during their next deployment. This should never be the case. They should run as the least-privileged accounts, with other processes around them to actually manage migrations between API version changes.

The same goes for pipelines. They should never run as a person with elevated permissions. They should run as a purpose-built identity, scoped to exactly what they’re meant to do: run the CI and CD pieces of those repositories. You should be using dedicated service principals per pipeline, per environment. Role assignments and security groups scoped to the resource group, not the subscription, are key. Federated credentials are how this should be done, and if you can’t do that, the next best thing is credentials and secrets whose keys can be easily rotated.

The goal is that the service principal can only do its job and nothing else. The scope of its activity is well-known. Even if it gets compromised, it can’t affect other systems. The blast radius is just its job description.

The Through-Line

The thread running through all eight is the same: every one of these controls lives outside the AI tool itself. None of them depend on the model behaving well. None of them depend on a prompt being phrased correctly.

Internal guardrails are a feature you hope works. External controls are a fact the agent runs inside. That’s the whole difference.

None of this is new. Enterprise security has known these patterns for a decade: PIM, environment separation, PR gates, secret management, network segmentation, audit logging, policy-as-code, least privilege. Every one of them predates the AI agent by years. What changed is the cost of skipping them. The deferred work that used to sit on a quarterly roadmap now has a clock on it.

AI didn’t create the security problem. It created the urgency.

Audit the Access Model Before You Adopt the Tool

The mistake is treating AI adoption as a tooling decision and the security posture underneath it as someone else’s problem to catch up on. The agent is going to inherit whatever access model you hand it on day one: every stale role assignment, every standing contributor grant, every SP nobody owns. If you wouldn’t trust a junior engineer with the access your identity currently holds, you shouldn’t trust an agent with it either.

Before the tool lands, walk the access model. Find the standing grants that should be JIT. Find the prod access living on dev identities. Find the service principals with subscription-scoped roles that need resource-group scope. Fix them while the stakes are still hypothetical.

You can’t prompt-engineer your way to production security. You can only build it once, outside the tool, and let the agent run inside the lines you’ve already drawn.