5 min readUpdated 2026-08-31Issue 1

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.

ByKarthik KumarCafiyn Innovations2026-08-31

At a glance

What changed: Agents moving from prompted to always-on and scheduled
Reported scale: Hundreds of automations per hour
Example flow: A PagerDuty incident starts an agent that queries server logs over MCP
The real question: What can it read, what can it change, and where is that written down
Category it falls under: Access control, the same as any other non-human identity

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

1List 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.
2Scope agent tokens to the specific services they need. Broadly scoped tokens issued for convenience are the most common finding in this category.
3Default agents to read-only. Make write access a separate decision with a name attached to it.
4Assume production logs contain personal data, and apply the same handling rules you would to a database with the same contents.
5Add agent credentials to your rotation schedule and your access review. A credential nobody reviews is one nobody revokes.

Common questions

Is giving an AI agent production access a bad idea?

Not inherently. It is the same class of decision as giving a service account or CI runner production access, and the same controls apply: least privilege, read-only by default, documented scope, and inclusion in access reviews. The risk comes from creating one informally rather than from the concept.

What is the biggest mistake teams make here?

Issuing a broadly scoped token because it was the one available, then never revisiting it. The agent works, so nothing prompts a second look, and the over-permission persists until something goes wrong.

Do production logs really count as sensitive data?

Usually yes. Logs commonly contain user identifiers, request payloads, email addresses, and tokens captured in error traces. Read access to logs is often read access to personal data regardless of how the permission is labelled.

Sources

Read against the primary documentation rather than secondary coverage. Where a figure comes from a provider's own docs, it is quoted as published on 2026-08-31.

Grade your access control in 3 minutes →Production checklist for a custom stack →