What Is AI Agent Visibility? Identity, Access and Activity

The Definition

AI agent visibility is the ability to identify the agents operating in an environment, understand the access available to them, and inspect evidence of their actions. Discovery, authorization records and activity logs provide different parts of that picture, and the whole picture only exists when the three can be read against each other.

An enterprise that has catalogued its agents tends to assume it understands them. A catalogue is a snapshot taken at registration, and an agent's behaviour on any given day has little to do with what was true when someone signed it off. Visibility is the continuous version: where agents are operating, what they are connected to, what data they reach, what actions they perform, and how that changes over time.

Three adjacent questions get their own posts, so this one can stay on the definition. Which systems to query, in what order, when something already looks wrong is the investigation sequence. Where observing an action ends and controlling it begins is visibility against governance. And the durable evidentiary record is the agent audit trail.

Identity, Access and Activity

The three parts of the definition are not three views of one dataset. They are three systems of record, each authoritative for one question and silent on the other two.

Table 1 — Three records, three questions. The right-hand column is why no one of them is "visibility".

Read the failure modes left to right and they get progressively more expensive. An environment with no identity layer cannot start an investigation at all, because there is nothing to filter on. One with identity but no access records can see activity and has no baseline to judge it against. One with all three, where the activity records carry the agent but not the human it acted for, produces a complete story about a service account and no answer to the question anyone actually asked.

Not Brand Visibility in AI Search

The phrase has two unrelated meanings and they are converging on the same keywords, so it is worth being explicit about which one this is.

In marketing, "AI visibility" or "agent visibility" has come to mean how often and how favourably an AI assistant mentions a brand when a prospective customer asks it a question. The subject is your public presence, the measurement is sampling model outputs, and the owner is a content team.

In security and operations, agent visibility is the subject of this post: the agents running inside your own environment, the access they hold against your own systems, and the evidence of what they did with it. The subject is software you are responsible for, the measurement is telemetry you collect, and the owner is whoever would be asked to explain an incident.

They share no methods and no data. If you arrived here looking for the first one, nothing below will help; the two are related only by having picked the same words.

Beyond a Static Inventory

The identity and access rows of Table 1 are the ones most enterprises already have, in the form of an inventory listing approved agents, their owners and their granted scopes — and an organisation can hold all of that and still have no idea how those agents are used. The activity row is where the rest of the definition lives, and it is several things a registration record cannot capture:

• Activity: which agents are running, how often, and against which systems.
• Behaviour: the patterns an agent settles into, and the moments it deviates.
• Permission usage: not what an agent could do, but what it exercises.
• Tool calls: the specific functions, APIs and queries invoked on each run.
• Failures: errors, retries, timeouts and rejected actions.
• Escalations and outcomes: what went to a human, and what resulted.

The inventory answers what should exist. Visibility answers what is happening. An inventory entry is a claim; visibility is the evidence that confirms or contradicts it.

MCP's security guidance makes the same point from the authorization side. Among the consequences it lists for publishing over-broad scopes is "audit noise: single omnibus scope masks user intent per operation", and its server guidance is to "log elevation events (scope requested, granted subset) with correlation IDs". Both are visibility requirements written into a protocol document, which is a reasonable signal that the field has stopped treating this as optional instrumentation.

Why Agents Need It

Agents are dynamic in a way ordinary software is not. A deterministic service does the same thing on every run. An agent reasons about a task and then chooses its path: different tools, different data sources, different users on whose behalf it acts, depending on what it meets along the way.

Take a data-analytics agent that answers ad hoc business questions. On Monday it joins two reporting tables and returns a summary. On Tuesday, asked a subtly different question, it reaches into a raw events warehouse holding personal identifiers it was never expected to touch. Nothing in the inventory changed. Its granted scope technically allowed both. Only the tool-call trace shows that the agent crossed into sensitive territory.

Figure 1 — Same agent, same permissions, two different Tuesdays. The inventory cannot tell them apart. Only a trace of the actual tool calls can.

A static record tells you what an agent is permitted to do. It cannot tell you what it chose to do. As autonomy increases, the gap between those two grows, and visibility is what closes it.

Questions Visibility Answers

A useful way to define agent visibility is by the questions it lets a security, compliance or operations team answer at any moment, without filing a ticket:

• Which agents are active right now, and which have gone quiet?
• What tools and integrations are they calling, and how often?
• What data are they reading or writing, and how sensitive is it?
• Which users, or which other agents, are invoking them?
• What actions are they attempting, and which succeed or fail?
• Are they operating inside their granted scope, or pushing at its edges?
• Are they behaving unusually compared with their own baseline?
• Are they suddenly exercising permissions they rarely or never use?

The last two are where visibility earns its keep. A marketing agent that routed campaign drafts to a review queue for six months and then starts publishing straight to the live audience has not necessarily been compromised, but it has changed, and the enterprise should know the moment it does. Behaviour relative to a baseline is a sharper signal than any single action viewed alone.

The Schema

The activity row of Table 1 is the part of the definition that has firmed up into a published vocabulary, so it is worth naming the actual fields rather than describing them abstractly. The OpenTelemetry GenAI semantic conventions moved into their own repository and now cover, in their own description, "prose and signal definitions for GenAI client inference, agents, tool execution, evaluation, and MCP", with an attribute registry for the gen_ai.*, mcp.* and openai.* namespaces. The protocol side moved with it: the MCP logging utility was deprecated in the 2026-07-28 revision, with the migration path recorded as "Log to stderr for stdio transports; use OpenTelemetry for observability".

Table 2 — The GenAI span set, with the attributes the conventions mark required. error.type is conditionally required on every span when the operation fails, and unlike the gen_ai.* keys it is already Stable.

A few of these carry more weight than their position suggests. gen_ai.agent.id and gen_ai.agent.name are conditionally required, which means an instrumentation that omits both produces spans nobody can attribute. gen_ai.conversation.id is what stitches a multi-turn run back together. On the MCP side, mcp.method.name is required and takes values such as tools/call, initialize and prompts/get, while mcp.session.id is recommended and mcp.protocol.version records which revision was negotiated. For resource reads, mcp.resource.uri carries the target, with examples in the convention as specific as postgres://database/customers/schema.

The metrics side is thinner but more useful for capacity work than traces are:

Table 3 — Five histograms that answer the cost-and-latency questions traces answer badly.

Now the caveat that belongs next to all of it. Every span, metric and attribute above is marked Development, and OpenTelemetry's stability policy is explicit about what that means: "breaking changes and performance issues MAY occur", components "should not be feature-complete", signals "may be entirely discarded", and "long-term dependencies are discouraged". Stable is the level that promises three years of support after the next major version. Nothing in the GenAI set has it.

Visibility in Practice

In practice, visibility means every meaningful step leaves a structured, queryable record tying together the agent, the user it acted for, the tool it called, the data it touched, the permission it used and the result. Expressed in the conventions, one observed tool call looks like this:

{
  "name": "execute_tool hris.update_employee_record",
  "kind": "CLIENT",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "attributes": {
    "gen_ai.operation.name": "execute_tool",
    "gen_ai.agent.name": "hr-onboarding-assistant",
    "gen_ai.agent.id": "agt_0f3c",
    "gen_ai.conversation.id": "conv_9812",
    "gen_ai.tool.name": "hris.update_employee_record",
    "gen_ai.tool.call.id": "call_7c21",
    "gen_ai.tool.type": "function",
    "mcp.method.name": "tools/call",
    "mcp.session.id": "sess_44ab",
    "app.acting_user.id": "rkim@corp.example",
    "app.permission.used": "hris.write:compensation"
  },
  "status": "OK",
  "start_time": "2026-06-18T14:02:11.221Z",
  "end_time": "2026-06-18T14:02:11.884Z"
}

Two of those keys are not from the GenAI conventions, and that is deliberate. The acting user and the permission actually exercised are the two fields an audit conversation always turns on, and the GenAI set defines neither. Both are custom attributes here, which is fine as long as the names are stable and documented in the same place as the dashboards that read them. If you emit nothing else custom, emit those two: they are the difference between aact:audit-granularity/per-action and aact:audit-granularity/per-action-with-principal-chain.

On its own, one record is unremarkable. The value is in the stream. When an HR onboarding assistant that normally writes job titles and start dates begins editing compensation fields, the permission attribute is the thread to pull. And because the record carries a trace_id, the sibling invoke_agent span tells you which run decided to make that call.

Figure 2 — One run as a span tree. The tool-call spans are the ones a security team reads; the plan and model spans are the ones an engineer reads.

The judgement call in all of this is content. Tool arguments and results are where the useful detail lives and also where the personal data lives, and the conventions take the conservative line: these attributes "may contain sensitive information" and "instrumentations SHOULD NOT capture this attribute by default", with capture gated behind an explicit configuration flag. We think that default is right, and the workable compromise is to capture argument shapes and result sizes always, full payloads only for a named subset of tools, and nothing at all for the ones touching regulated data.

Five things go wrong with this in the first month, and they look like different problems than they are.

Table 4 — Five instrumentation failures, and the query that distinguishes each.

The last row is the expensive one, because it is the one that turns a security question into an investigation. An agent running under a single service account produces traces that are complete, well-formed and useless for answering who it acted for. That field has to be threaded through from whatever authorized the call, and no tracing library will do it for you.

Without this layer, enterprises are left to trust that agents behave as expected. With it, they can verify continuously and respond when something shifts.

Visibility as Improvement

Visibility is usually framed as a control function, and it is also one of the most direct levers on agent quality. The same traces that catch a security drift show exactly where an agent struggles.

Suppose an IT operations agent handling routine access requests succeeds nine times in ten, and the tenth consistently fails when the request touches a particular legacy directory. The traces show the failures clustering on one gen_ai.tool.name, show three retries before the agent gives up, and show a human pulled in every time. That is not an abstract reliability number. It is a map of where the workflow, the integration or the instructions need work.

The same applies to silent inefficiency. gen_ai.invoke_agent.tool_calls is a histogram for a reason: an agent that calls a slow legal-contract search five times when one well-formed query would do is not failing, it is spending time and money, and the distribution is where that shows up. We think this is the more persuasive case for visibility inside most organisations, even though it usually gets sold as a security control first. It pays for itself in a quality review long before it catches anything malicious.

Where It Fits

The three parts of the definition differ in tense, which is also how they split across systems:

• Inventory holds what should exist: the agents, owners and scopes on record. Identity and access.
• Live telemetry shows what is happening: current activity, behaviour and permission usage.
• Audit trails preserve what did happen: the durable record kept for later review.

The last two are both activity, and they are usually different stores with different retention and different costs. Conflating them is why a question about last quarter is sometimes answered with a dashboard that only goes back a fortnight.

The third row is also where the obligations land, and they are less exotic than the discussion around them suggests. The EU AI Act's Article 12 requires that high-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system", and Article 26(6) requires deployers to keep those logs for a period appropriate to the purpose and "of at least six months". Those duties apply from 2 December 2027 for Annex III systems. NIST's AI Risk Management Framework, published as NIST.AI.100-1 in January 2023, organises the surrounding work into Govern, Map, Measure and Manage, and OWASP's Top 10 for Agentic Applications for 2026, published on 9 December 2025, is the current peer-reviewed risk taxonomy to map traces against.

One short product note, since the question comes up. Agentic Fabriq carries two identities on every call, the agent and the acting user, and writes an audit record for each into BigQuery-backed storage with dashboard filters over it; export is API-only, as NDJSON. It is the record-keeping half of what this post describes, not a substitute for instrumenting your own agent runtime.

Frequently Asked Questions

What is AI agent visibility? The ability to identify the agents operating in an environment, understand the access available to them, and inspect evidence of their actions. Discovery, authorization records and activity logs provide different parts of that picture. Concretely, in 2026, the activity part means emitting spans conforming to the OpenTelemetry GenAI conventions and being able to query them.

Is this the same as being visible in AI search? No. That sense of the phrase is about how often an AI assistant mentions your brand, and it is a marketing measurement taken from model outputs. This post is about agents running inside your own environment and the telemetry they leave behind. The two overlap only in wording.

What are the three parts of agent visibility? Identity, which agents operate here and who owns each; access, what each is permitted to do and on whose behalf; and activity, what it actually did, when, for whom and with what result. Each comes from a different system of record, and none of the three is sufficient alone.

How is agent visibility different from observability? Observability is the general practice and mostly serves engineers. Agent visibility is the subset aimed at a second audience, security and compliance, and it adds two fields ordinary tracing omits: the user an action was taken for, and the permission it consumed.

What should an agent trace record contain? At minimum gen_ai.operation.name, the agent identity (gen_ai.agent.id or gen_ai.agent.name), the tool (gen_ai.tool.name and gen_ai.tool.call.id), error.type when it fails, and the conversation or trace identifier that links the run. Add the acting user and the permission exercised yourself, because the conventions do not define them.

Do I need OpenTelemetry for agent visibility? No, but the alternative is inventing names for the same fields. It is also the direction the protocol layer is moving: MCP deprecated its own logging utility in the 2026-07-28 revision and points implementers at OpenTelemetry, with the feature eligible for removal in the first revision released on or after 28 July 2027.

Are the GenAI semantic conventions stable? Not yet. The spans, metrics and attributes are marked Development, which OpenTelemetry defines as a level where "breaking changes and performance issues MAY occur" and long-term dependencies are discouraged. Adopt them, and keep a mapping layer between the emitted names and your queries.

Does tracing every tool call leak sensitive data? It can, which is why the conventions say instrumentations "SHOULD NOT capture this attribute by default" for tool content. Capture the call shape and the outcome always; capture payloads only for tools you have decided it is safe for.

How long do I have to keep agent logs? If the system is high-risk under the EU AI Act, Article 26(6) sets a floor of at least six months for deployers, and sector rules can run far longer. Retention is an audit-trail question rather than a visibility one, and the two are usually different stores with different costs.

Is a static agent inventory enough? No. An inventory covers the identity and access parts of the definition and nothing else: it is a claim about permission recorded once. The activity part is the evidence about use, collected continuously, and the gap between claim and evidence widens with every increase in autonomy.

Conclusion

Treat agent visibility as a prerequisite rather than instrumentation bolted on after an incident. Visibility deployed early shapes how agents get built and permissioned. Visibility added late is forensic at best.

The rule scales cleanly with risk: the more autonomy an agent has, the more visibility it needs around it. A finance agent that drafts a report and one that initiates payments deserve very different scrutiny even if they share a codebase.

What changed recently is that this stopped being a design argument and became an implementation task. The span names exist. The attribute keys exist. They are not yet stable, they do not include the two fields compliance will ask for first, and neither of those is a reason to wait, because the alternative to an imperfect shared vocabulary is a private one that nobody else can read.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — the audit-granularity dimension, whose top two terms are exactly the gap between the GenAI conventions as published and the two attributes added above.
• OpenTelemetry GenAI semantic conventions repository — the move out of the core semconv repo, and the scope covering agents, tool execution and MCP.
• Semantic conventions for GenAI agent spans — the create_agent, invoke_agent, invoke_workflow and plan spans, their kinds, and the required and conditionally required attributes.
• Semantic conventions for GenAI spans — the execute_tool span, gen_ai.tool.name and gen_ai.tool.call.id, and the default-off rule for capturing tool content.
• Semantic conventions for MCP — mcp.method.name, mcp.session.id, mcp.protocol.version, mcp.resource.uri, and the client and server span kinds.
• Semantic conventions for GenAI metrics — the agent, tool and client histograms with their units and stability.
• OpenTelemetry versioning and stability — what Development and Stable each guarantee, and the three-year support commitment that only Stable carries.
• MCP specification: deprecated features — Logging deprecated in 2026-07-28, OpenTelemetry named as the migration path, earliest removal on or after 2027-07-28.
• MCP Security Best Practices, 2026-07-28 — audit noise from omnibus scopes, and the guidance to log scope-elevation events with correlation IDs.
• EU AI Act Article 12: Record-keeping — the automatic event-logging requirement over the system lifetime, and the 2 December 2027 date for Annex III systems.
• EU AI Act Article 26: Obligations of deployers — paragraph 6 and the six-month log retention floor.
• NIST AI Risk Management Framework — NIST.AI.100-1, published 26 January 2023, and the Govern, Map, Measure and Manage functions.
• OWASP Top 10 for Agentic Applications for 2026 — the peer-reviewed agentic risk list, published 9 December 2025.