Kyro Security Blog

Your service account looks unused. It probably is not.

Wed, 19 Aug 2026 00:00:00 GMT

Somewhere in your Google Cloud console there is an insight telling you a service account has not been used in 90 days, and suggesting you disable or delete it.

It is probably right. It might also be describing an account that a running production workload depends on right now.

Both of those can be true at once, and the reason is worth understanding before you action the list.

What the check actually measures

The feature is service account insights, which Google labels Pre-GA. It flags an account when it has not authenticated in the last 90 days.

That is a real signal and a reasonable one. Every call to a Google Cloud API authenticates as some principal, and that authentication is recorded. If nothing has authenticated as this account in three months, that is genuinely suspicious.

Read the sentence carefully, though. It is not “has not done anything.” It is “has not authenticated to a Google Cloud API.”

Those are the same thing only if everything your workload does is a Google Cloud API call.

Which, for a lot of workloads, it is not

Picture a service running in GKE, using Workload Identity Federation for GKE to impersonate a Google service account. Its Kubernetes ServiceAccount is bound to that account:

role:   roles/iam.workloadIdentityUser
member: serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]

That impersonation path is the one most clusters are on. Google’s current best practice is the other one: reference the Kubernetes ServiceAccount directly as an IAM principal, with a principal:// identifier and no intermediate service account at all. On that path none of what follows applies, because there is no service account left to flag. Impersonation stays documented and supported, because direct access still carries per-API limitations, so plenty of clusters will be on it for a long time yet. If yours is one, read on.

Now think about what that service spends its day doing.

It reads and writes to its own Postgres. It calls two internal services over the cluster network. It hits a model endpoint. It pulls from a bucket in another cloud, because that is where the data landed. Maybe once a night it writes a summary to Cloud Storage.

Every one of those is real work. Exactly one of them authenticates to a Google Cloud API.

If the nightly job is paused for a quarter, or moved, or the bucket write gets refactored away, the account goes quiet by this measure while the service keeps running perfectly. Ninety days later it appears on a list of things to clean up.

Google is precise about what resets the clock:

Whenever a service account or key is used to call a Google API, including an API that is not part of Google Cloud, it generates an authentication activity.

Tools to understand service account usage, Google Cloud documentation.

Failed calls count. Calls to Google APIs outside Google Cloud count. What does not count is everything else the workload does all day, because none of it is a call to a Google API. A pod can saturate its node for a quarter and produce nothing this measure can see.

Delete the account and the pod loses its identity. Not immediately, and not loudly: the GKE metadata server caches access tokens, and those are good for an hour by default. It fails the next time it needs a new one.

Google says this itself

This is not a gotcha, and it is not a criticism of the feature. The documentation is upfront about it:

We recommend cross referencing service account insights with Cloud Monitoring service account usage metrics before you disable or delete a service account.

Service account insights, Google Cloud documentation.

That sentence is worth reading twice, because it tells you the two signals are not the same. Insights and Activity Analyzer do not track authentication against Google APIs that sit outside Google Cloud. The Cloud Monitoring usage metrics do, including those APIs. That is the whole reason for the cross reference.

There is one more stated gap that neither side covers: requests authenticated by API keys bound to a service account are not recorded in the usage metrics at all. Google’s own conclusion is that “these service accounts might be reported as unused.”

Then there is the arithmetic of the cross reference itself. The insight looks back 90 days. Cloud Monitoring, per its own documentation, “retains service account metrics for 6 weeks.” The second source runs dry around six weeks into the window the first source is judging. For anything that last authenticated two months ago, the check you have been told to run has nothing left to say.

A tool telling you to check its output against a second source before acting is telling you something about the confidence of that output. It is worth doing. It is also worth knowing that doing it fully is not possible.

The second thing, which is quieter

There is a related problem in the same data, and it does not announce itself with a recommendation you can decline.

When a GKE pod uses Workload Identity Federation for GKE, the call is made as the Google service account. The audit log records that the service account called storage.objects.get, which is correct and which is what the usage analysis reads.

The interesting part is that the log knows more than that. For GKE workloads it also carries serviceAccountDelegationInfo[].principalSubject, and inside that string is this:

serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]

Which is the same shape as the IAM binding further up this page. The namespace and the Kubernetes ServiceAccount are sitting in the log, in a field the usage analysis does not look at. It will not tell you the pod or the deployment, but it is a good deal more than nothing, and it is being ignored rather than missing.

Two things about where those entries live. Admin Activity logs always carry the field and cannot be turned off, so for anything that writes configuration it is reliably there. Data Access logs, which is where most ordinary data-plane calls land, are disabled by default for nearly every service, so on a lot of clusters those entries are never written at all.

Which means the answer is partly sitting in a log you cannot switch off and nobody is reading, and partly in one most people never switched on.

Now suppose five workloads share that service account, which is a normal thing to have done. They produce one usage profile between them.

If workload A needs storage.objects.delete and the other four do not, the account keeps the permission. It is used, after all. Four workloads stay over-permissioned and nothing in the data can tell you that, because from the outside all five look like one very busy identity.

Google’s own guidance is to create single purpose service accounts, and this is one of the reasons why. Every workload you attach to an existing account is a workload whose usage you can no longer see on its own.

One root, two symptoms

Both of these come from the same place.

The evidence is attributed to the identity that made the call. Your risk lives at the workload that holds the identity. Those are different things, and everything that goes wrong here goes wrong in the gap between them.

Half of the bridge exists. The audit log carries the namespace and the ServiceAccount, and the IAM binding carries them too. Nothing in the system reads either one and turns it into a relationship you can act on, so that half is sitting there unused rather than missing.

The other half is not sitting anywhere. Read every audit log in the project perfectly and you learn what the workload did to Google. You learn nothing about the Postgres, the internal services, the model endpoint, or the bucket in the other cloud, because none of those produce a cloud audit record at all. Those are the dependencies that decide whether trimming the role breaks anything, and the cloud has never seen them.

So the tooling can tell you, accurately, that an identity has been quiet. It cannot tell you whether a workload depends on it. It can tell you, accurately, that a permission was exercised. It cannot tell you which of the five things behind that identity exercised it, or what happens to the other four if you take it away.

The question that is left

None of this makes the recommendations wrong. Most of them will be correct, and acting on them will genuinely reduce your exposure.

It just means the list is a starting point rather than a work queue. Every row on it comes with a question the row itself cannot answer:

If I delete this, what stops working?

The cloud’s own record gets you partway. It can name the workload behind the identity, the day something bothers to read a field it already writes. It cannot tell you what that workload depends on, because most of what a workload depends on never touches a Google API and therefore never shows up.

Which points at where the answer actually is. Not in a better reading of the identity, which is what every tool here is already doing, but in watching the workload: what it reaches for, what answers, and who goes quiet if the permission disappears. The identity tells you what was allowed. Only the workload tells you what was needed.

Three kinds of agent, and only one is yours

Tue, 04 Aug 2026 00:00:00 GMT

Someone at your company has been asked how many AI agents you are running.

They cannot answer it. Not because nobody looked, but because “agent” turns out to mean three completely different things, and only one of them is yours.

Here is the test. Pick any agent someone names and ask one question:

Who issued its credentials?

That sorts it into one of three piles. The piles have almost nothing to do with each other, and mixing them together is why the count never lands.

1. You issued them

A nightly job that reconciles inventory. Someone wrote it a role in Terraform, and a second person reviewed it.

Now there is a model in the loop, so people call it an agent. Nothing else changed. Your account issued the identity. Your team wrote the permissions. Every call it makes shows up in your own logs.

This is the boring pile, and the boring pile is the one with answers:

You can list them.
You can read what each one is allowed to do.
You can see what it actually did.
You can delete one this afternoon and know by tomorrow what broke.

All four of those are true. Hold onto the last one, because it is doing more work than it looks like it is.

2. Someone else’s software brought them

Your document tool ships an assistant that answers questions by reading across every file in the workspace.

Nobody on your team built it. It showed up in a release note.

It runs on the vendor’s servers, under the vendor’s identity, and it reaches your data through a permission an admin granted once. Probably by clicking through a consent screen. Possibly by leaving a default switched on.

You cannot list these. You can only list the permissions you granted, and that is not the same thing. “Read files in this workspace” does not tell you whether one assistant uses it or forty, whether the vendor added another one last Tuesday, or what any of them did once they were in.

Your only real lever is that consent, and consent is usually all or nothing. Keep the integration and its access, or rip it out and lose the feature a whole department asked for. Nobody who has tried to revoke half an OAuth scope mid-quarter would call that control.

You fix this pile through contracts and procurement, not through your cloud console.

3. Nobody issued them

A coding assistant on an engineer’s laptop, running on a personal access token they minted from their own account and pasted into a config file. Scoped generously, because scoping it properly would have taken twenty minutes and the work was due.

There is nothing to revoke here, because nothing was ever issued. What exists is a credential that works, belonging to a human whose access was sized for a human working at human speed.

When that person leaves, offboarding closes their accounts. It does not know about the token in a config file on a laptop that has already been wiped, or the copy in a personal repository, or the small script a teammate now quietly depends on.

This is the pile that keeps people up at night, and it is the one you can least count by asking. Surveying engineers about which assistants they run measures memory and honesty, not credentials.

So why does the big number keep coming up?

Because of forecasts like this one:

By 2028 an average global Fortune 500 enterprise will have over 150,000 agents in use, up from less than 15 in 2025.

Gartner Press Release, Gartner Identifies Six Steps to Manage AI Agent Sprawl, 28 April 2026.

The forecast is not the problem. The question people attach to it is.

Suppose you did the counting and came back with one big number. What would you actually do with it?

Headcount for managing identities in your own accounts comes out of pile one. How hard you push on vendor review is pile two. Secret scanning, shorter token lifetimes, and making the approved path fast enough that nobody works around it is all pile three.

Three piles, three owners: your platform team, whoever signs the contracts, and for the third one, quite often nobody.

“150,000 agents” cannot be handed to anyone, because its three parts come out of three different budgets and get fixed by three different groups of people.

Ask the smaller question instead

Not “how many agents do we have.”

How many agents are using credentials we issued?

That one you can answer from records you already keep. It is also the only pile where you can see behaviour rather than paperwork: what the thing actually did, not what somebody once agreed it could do.

The fair objection

This is convenient, is it not. Draw a circle around the easy pile, call the rest someone else’s job, go home.

Worth answering directly: piles two and three matter. Three is probably where your worst single incident comes from.

But neither gets better by counting. Pile two improves when consent is negotiated narrowly and renegotiated at renewal. Pile three improves when the reason to mint a personal token goes away, which usually means the sanctioned path was slower than the shortcut. Neither of those starts with a census.

The count was never the hard part

Back to that last bullet in pile one.

You can list those identities today, and most teams already have. Somewhere in your organisation there is a spreadsheet of service accounts with a “last used” column, and it has been accurate and ignored for eighteen months.

The list is not what is missing. What stops anyone deleting a row from it is the question the list cannot answer:

If I take this permission away, what stops working?

An inventory can tell you a permission has not been used in ninety days. It cannot tell you whether the job that needs it runs quarterly. It cannot tell you that two services share the identity and only one of them went quiet. Unused and safe to remove are not the same thing, and everything expensive lives in the gap between them.

That is why the pile you own is fully catalogued and completely untouched. Not because nobody counted. Because counting was never the part that was hard.