Every asset is an AI asset (Part 2): the things you’re not tracking like assets

Try this: pick one AI agent running in your environment and ask four questions about it. 

1. Who “owns” it? 

2. What can it access? 

3. How much does it matter? 

4. When does it get turned off? 

For a laptop, someone can *probably* come up with an answer for all four questions, though even that’s harder than it looks, too. For the agent, you’ll be lucky to get an answer to even one.

That challenge is what this post is about. 

In Part 1, I covered how every asset now runs AI, feeds AI, or gets acted on by AI, and that an agent reasoning from a stale inventory will compound your mistakes at machine speed. The answer was durable context: a persistent, reconciled picture of your environment that any tool or agent can trust. This post is about the assets that make that picture hardest to keep clear - the ones multiplying fastest and governed least…can you take a guess? Yup, AI assets. 

The inventory you already have 

The AI asset management challenge exists because three fast-growing classes of assets likely don’t go through the same provisioning process as everything else. 

• AI agents. The copilots, autonomous remediation bots, and task runners your teams stood up to move faster. Each one authenticates with credentials, calls tools and APIs, and acts on your environment - sometimes on a schedule, increasingly on its own.

• Machine identities. Service accounts, API keys, personal access tokens, OAuth client secrets, workload identities and IAM roles, and TLS certificates. Some are short-lived and auto-rotating; most are long-lived static keys that never expire on their own. 

• AI services. The models, endpoints, and MCP connections wiring your data and tools into LLMs. An MCP server exposes tools and data to an LLM client, holds its own credentials, and can broker a single agent’s reach across a dozen backend systems at once. And because the agent selects which tool to call from natural-language descriptions interpreted at inference time, loose scope on that server is a live problem, not a theoretical one. 

None of these are surprising. They were just never onboarded like assets. And, let's face it, even the “standard” assets in your environment are tough to inventory. AI assets only compound that challenge. 

And this isn’t a niche worry. Palo Alto Networks’ 2026 Identity Security Landscape report puts machine identities at 109 to 1 against humans, up from 82 to 1 just a year earlier, and calls AI agents the fastest-growing slice - respondents expect 85% agent growth in the next 12 months alone. 

GitGuardian’s 2026 secrets research tells the same story from the credential side: leaked AI-service secrets jumped 81% year over year, and the LLM plumbing (orchestration, RAG, vector stores) leaked five times faster than the model providers themselves. The AI layer is scaling faster than anyone’s governing it.

What “tracking AI agents like an asset” actually means

Strip away the AI novelty and an agent is one more thing in your environment that holds access and does work. Industry data shows exactly where it breaks down: in that same Palo Alto study, most organizations could explain what their AI agents are for, but far fewer could say what those agents can access, how that access is limited, when their permissions get revoked, or what else can inherit them. That’s four fundamentals - the same ones we apply to a laptop - restated as a gap:

• An owner on record. A named human accountable for it. When something goes wrong you know who to call. The catch: the credential is bound to a workload or service, not a person, so there’s no HR record or manager to trace it back to. Most agents and service accounts have no owner listed at all.

• A defined access scope. The OAuth scopes and IAM policies attached to the identity. Least privilege is the goal. The reality is that the service account wired to a model gets whatever was convenient on day one (full read/write when read-only would actually be enough) and keeps standing access where just-in-time would be safer.

• A criticality rating. How much it matters. You’d treat an agent that can quarantine production workloads differently from one that drafts meeting notes.  It’s really a blast-radius question: an over-scoped token that gets compromised is a path to lateral movement across every system it can reach. With no rating, an alert about either one looks the same.

• A lifecycle. When it was created, whether it’s still needed, and when it retires. Laptops get reclaimed when someone leaves. The agent your platform team stood up for a project that shipped last quarter is still running, still holding access, with no expiration date.

Run any AI asset against those four and the gaps show up fast. These are the OG concepts that haven’t been entirely applied to AI yet. 

Why this is challenging 

It largely comes down to where these assets live.  

• They’re scattered. Your agents live in a cloud platform (AWS IAM, Entra, GCP), their secrets in a vault or KMS, their identities in your IdP, their runners in CI/CD, and their scopes in a SaaS admin console. No single system sees all of it, and none of them reconcile with each other. The hard part isn’t finding any one of them - it’s joining a credential to the workload that uses it and the human who owns it. Ask “how many AI agents do we run, and what can each of them access,” and you’re stitching together five exports by hand, just like you do with many asset-related questions.

• They skipped change control. A new employee goes through onboarding, an access review, and a deprovisioning process on the way out. Most agents and service accounts were created by a developer solving a problem in the moment, outside all of that. There was never a step that wrote them down.

• The basics were already hard. Security and IT teams struggle to keep a clean inventory of laptops and servers, assets we’ve been tracking for decades. AI agents pile onto that challenge, faster and with less structure. You can’t govern what no single system agrees exists.

Bring AI assets into your inventory

The answer here is not a dedicated AI asset tool sitting next to the tools you already have. That just adds a sixth silo to the five you’re reconciling by hand.

The answer is to pull nonhuman and AI assets into the same correlated inventory as everything else you own - correlating identity across IAM, your IdP, the secrets manager, and CI/CD into a single record keyed to owner, scope, criticality, and lifecycle. The agent, the service account it authenticates with, the model it calls, and the workloads it can touch belong in one picture. When ownership, access, and lifecycle live in one place instead of five, you can answer those four questions about an agent in thirty seconds, the same as you can for a laptop.

That’s the durable context from Part 1, extended to the assets that need it most. It’s a principle before it’s a product: whatever you’re missing for laptops, you’re missing worse for agents, and the fix is the same. Get them into one model you can trust.

The takeaway

The AI assets multiplying in your environment aren’t a “one and done” visibility problem. They’re a governance problem. Seeing the agent is step one. Knowing who owns it, what it can reach, how much it matters, and when it retires is the actual work.

Get that right and you’ve set up the question Part 3 is about: once you can see and govern these assets, what should you actually let AI do with them? That’s where see-and-govern becomes act-with-confidence. See you there.