How do you get visibility into AI-native systems?

Visibility into an AI-native system means being able to answer what it is made of, what it can touch, and what it did. Build an inventory of models, prompts, data sources and tools, then log inputs, tool calls and outputs so you can investigate and contain failures.

What is different about AI systems?

A conventional service runs code you wrote and reviewed. An AI-native system also runs a model whose behavior depends on training data and on whatever text arrives at runtime. The OWASP AI Exchange describes agentic systems as ones where a model's inference can specify actions to perform without per-action human approval. That sentence is the reason visibility matters: if software can act without sign-off on each step, you need a record of what it decided and why.

What belongs in the inventory?

Start with things that change independently of your code:

• Models: which provider or checkpoint, which version, who approved it.
• Prompts and system instructions: stored and versioned like code.
• Data sources: documents, databases and search indexes the system reads from, since untrusted content can carry instructions.
• Tools and permissions: every API, file path and command the model may invoke, and under whose identity.
• Dependencies: the libraries and packages in the serving stack, which carry ordinary vulnerabilities.

The OWASP AI Exchange organizes its guidance around threats at input time, development time and runtime, which maps neatly onto where you need to look.

What should you log?

Log enough to reconstruct an incident without storing more sensitive data than you need. Useful fields include the model and prompt version, the identity of the caller, which tools were invoked with which parameters, which data sources were retrieved, and the final output. The OWASP AI Exchange table of lifecycle questions asks it plainly: can failures, abuse and behavioral drift be detected, investigated and contained? If your logs cannot answer all three, you have a gap.

A constructed example

A support assistant can read a ticket system and issue refunds up to a limit. One week, refund volume doubles. With only application logs, the team sees HTTP calls and nothing else. With tool call logs tied to prompt versions, they see that a new prompt revision made the model more willing to refund, and that a retrieved ticket included text asking for a refund. They roll back the prompt, add a human approval step above a threshold, and flag the ticket source as untrusted input.

How does this connect to risk frameworks?

NIST's AI Risk Management Framework is voluntary guidance on incorporating trustworthiness into the design, development, use and evaluation of AI systems, and NIST has said it is being revised, so check the current version. NIST AI 100-2 provides a taxonomy and terminology for adversarial machine learning, which helps teams describe attacks in a shared vocabulary when they write detection rules.

Visibility also has a people side. Decide who reviews the logs and how often, and what counts as unusual enough to page someone. A log nobody reads is only evidence after the fact. Start with a few simple alerts, such as an agent calling a tool it has never used, or a sudden jump in volume, and add more as you learn what normal looks like. Keep retention long enough to cover a slow incident, and agree up front how long prompts and outputs containing personal data may be stored.

How to check or apply this

1. Create a register of every model, prompt, tool and data source in production.
2. Give each agent or service its own identity so actions are attributable.
3. Log tool calls with parameters, not only final answers.
4. Version prompts and models, and record the version on every request.
5. Treat retrieved content as untrusted input and note its source.
6. Set limits on what any single agent can do, and alert when it nears them.
7. Rehearse a rollback.

Quick check

Sources

• OWASP AI Exchange, AI Security Overview
• NIST AI Risk Management Framework
• NIST AI 100-2, Adversarial Machine Learning taxonomy

Last reviewed: 18 October 2026.