An agent with production log access is a new identity. Treat it like one.

Always-on agents that read production logs are arriving fast. The access-control question they raise is old and well understood, which is the good news.

What is actually being shipped

Cursor introduced Automations for always-on agents, describing systems running hundreds of automations per hour, including incident response where a PagerDuty incident starts an agent that immediately queries server logs through an MCP connection.

That is a genuinely useful pattern. The first ten minutes of an incident are mostly retrieval, and retrieval is something a machine does faster than a person at 3am. The reason to think carefully about it is not that the idea is bad. It is that the setup quietly creates something your access model may not account for.

The thing that is new, and the thing that is not

An agent that reads production logs is a principal in your system: something that authenticates, holds permissions, and takes actions. We have had those for years. Service accounts, CI runners, and monitoring agents are all non-human identities, and the practices for handling them are well established.

What is different is how easy this one is to create. A service account usually involves a ticket, a review, and someone deciding what it may touch. An agent integration can be added by one engineer in an afternoon, inherit a broadly scoped token because that was what was available, and never appear in the access review because nobody thought of it as an account.

The other difference worth naming: production logs are not low-sensitivity. They routinely contain user identifiers, request payloads, tokens in error traces, and email addresses. Read access to logs is frequently read access to personal data, whatever the access-control list says it is.

Three questions before you wire one up

None of this requires new theory. It requires answering the same three questions you would answer for any service account, before rather than after.

What can it read? Scope to the specific logs or services needed, not the whole estate because that was the easier token to issue.

What can it change? Read-only is a legitimate and often sufficient answer for incident triage. Write access should be a separate, deliberate decision.

Where is that written down? If the answer lives only in one engineer's memory, it will not survive their next holiday, let alone an audit.

Why this shows up as a grade, not a headline

Access control is one of the ten categories most likely to be the reason a small team has a bad month, and it is consistently among the weakest in self-assessments, because it is invisible while it is wrong. Nothing fails. There is no error. There is simply a credential that can reach more than it should, until the day that matters.

Adding an autonomous agent does not change that category, it adds a member to it. The useful move is to fold agents into whatever review you already do for service accounts, rather than treating them as a separate new problem that needs a separate new policy.

What to do

List every non-human identity that can reach production, and add your agents to that list. If the list does not exist, it is the first thing to write.

Scope agent tokens to the specific services they need. Broadly scoped tokens issued for convenience are the most common finding in this category.

Default agents to read-only. Make write access a separate decision with a name attached to it.

Assume production logs contain personal data, and apply the same handling rules you would to a database with the same contents.

Add agent credentials to your rotation schedule and your access review. A credential nobody reviews is one nobody revokes.