The Friday Agent Permission Audit [Checklist]

It’s Friday. You have 90 minutes before the weekend. Here’s what you can check, fix, and document before Monday. These are the problems most teams only spot after something breaks.

The quick version: Permission drift happens slowly, and nobody schedules time to catch it. A short, regular audit beats a long, rare one. This is hygiene, not a project.

Running a regular agent permission audit catches the governance gaps that most teams only discover after an incident. NIST 800-53 access control families and CIS Controls for identity both emphasize continuous monitoring as the foundation of access governance. This checklist operationalizes that principle in 90 minutes.

How many agents are running in production right now?

Start with inventory. You’d be surprised how often teams can’t answer this cleanly. Check your deployment logs, your container orchestrator, your serverless dashboard. Count every agent currently active.

Write the number down. If you can’t get an exact count in five minutes, you’ve found your first problem.

Does each agent have a unique identity?

Agents sharing service accounts are like flatmates sharing a single key to the apartment. If one breaks something, nobody knows which one. If you need to revoke access to one agent, you break them all.

Check your IAM setup. Every agent should authenticate with its own identity. If you find shared accounts, that’s a 30-minute fix: rotate them to individual credentials and update the deployments.

Which agents have write access to production databases?

Not all agents need to write. Some only read. Some don’t touch databases at all. Map it out. If an agent has write access it shouldn’t have, it’s sitting there waiting to be exploited.

This is where permission drift usually lives. An agent got write access for a feature that shipped months ago. Nobody removed it.

Which agents can make external API calls, and to where?

Agents that call external services can leak data. They can also be hijacked. Know exactly which agents call out and what endpoints they hit.

If an agent can reach any API it wants, tighten the network policy. Allowlist the specific endpoints it needs. Treat external connectivity like you’d treat a door in a building: lock it unless there’s a reason it should be open.

When was each agent’s permission scope last reviewed?

You need a date for each one. Not “sometime in Q3.” An actual date in a spreadsheet or your audit log.

If the date is more than three months old, review it today. If it’s more than six months old, treat it as expired. Permissions don’t age well. Systems change. Dependencies change. What made sense in January might be wrong in March.

Are there any agents using API keys that haven’t been rotated in 90+ days?

Old keys are debt. They accumulate access over time. Someone might have left a key in a log file, a GitHub commit, a Slack message from 2024. Rotation cuts off stale exposure.

Check your secrets manager. Make rotation automatic where you can. If you’re rotating manually, set a calendar reminder for the first Friday of every month to do it then.

Which agents can access PII or financial data?

This is the high-risk check. If an agent touches personally identifiable information or payments, it needs explicit oversight. Lock the access pattern down. Add logging. Know every request. OWASP Top 10 for LLM Applications for agent security mandate that PII access be restricted to the minimum viable scope and monitored continuously.

If an agent accesses PII and nobody’s looked at its permissions in six months, fix that today.

Is there an owner assigned to every agent?

Each agent should have a person’s name next to it. Not “the team.” A specific person. They get paged if something goes wrong. They review permission changes. They certify every quarter that the scope still makes sense.

If you find an agent with no owner, assign one now.

Are there any agents running that nobody on the current team deployed?

This is the ghost check. You inherit systems. People leave. Containers keep running. You might have an agent running that shipped years ago and nobody on your current team even knows what it does.

If you find one, track down the original owner or reverse-engineer it from logs. Then decide: keep it with proper ownership, or shut it down.

---

This is like brushing your teeth versus going to the dentist. Both prevent problems. One catches the small stuff before it becomes a root canal.

Your current team didn’t deploy every agent. Your permissions drifted since last month. Some keys haven’t rotated. You’ve got a ghost service running somewhere. These aren’t failures. They’re what happens when teams focus on shipping. Audits are how you clean up after velocity.

Run through this checklist today. Spend 10 minutes per agent. Document what you find. Then set a calendar invite for the first Friday of next month to do it again.

The agents that fail audits aren’t your biggest security problem. The ones you never audit are.