Before Dataiku Agent Management Goes Live, How Should Enterprises Inventory AI Agents? 2026 Checklist

You have Agents running across separate platforms, and no one can say who owns all of them.

The fastest fix is to start an inventory now: assign owners and purposes, rank risk using your own evidence, and record monitoring and execution boundaries separately. Dataiku announced Agent Management on September 24, 2026, and said it plans to make the product generally available in October; the exact date and scope at launch remain subject to official updates. Its monitoring records do not replace permission controls or runtime isolation. Dataiku’s announcement

Platform engineers: use this checklist to map Agents across managed platforms and custom environments.
Security and AI governance leads: prioritize Agents that handle sensitive data, face customers, or can take consequential actions.
Engineering and business owners: make sure every Agent has a confirmed purpose, accountable owner, and a decision path for continued operation.

The decision: build the inventory before the product launch; do not wait for a dashboard to tell you what you run.

Last updated September 26, 2026. Timing, product scope, and described capabilities were checked against Dataiku’s September announcement and its product blog. Product descriptions below are vendor disclosures, not independent compatibility or performance tests.

Dataiku Agent Management launch preparation starts with an honest inventory

An enterprise inventory is not just a list of platform accounts. It needs to let you answer: what is this Agent meant to do, what can it access, where does it execute, and who can stop or change it?

Dataiku describes Agent Management as a way to discover Agents across platforms, monitor their operation, and manage risk. Its product materials also describe an Agent inventory, operational monitoring, and risk records. Those are the vendor’s stated capabilities, not proof that every Agent in your estate will be discovered automatically or that every listed risk will be controlled. Dataiku’s product description

Treat the announced integrations and OpenTelemetry support for custom environments as a coverage boundary to verify, not a promise of universal compatibility. Identify which environments are covered by a stated integration, which could report through OpenTelemetry, and which still need manual registration. OpenTelemetry describes instrumentation as the means of adding telemetry to software; it does not, by itself, guarantee that a particular Agent exposes useful or complete signals. OpenTelemetry’s instrumentation overview

Inventory approach	What it can establish	What it cannot establish by itself	Decision
Vendor-listed platform integration	Whether an environment appears within the vendor’s stated integration scope	That every Agent, version, or relevant signal in that environment will be found	Verify actual coverage against your running deployments
OpenTelemetry-based custom environment	Whether your team can instrument a custom environment and send supported telemetry	That an uninstrumented Agent is visible, or that telemetry enforces permissions	Test signal coverage and retain an owner for manual gaps
Human-maintained record	Ownership, purpose, dependencies, and environments that discovery misses	That the record remains current without a renewal process	Require a named reviewer and update trigger

Use one record per Agent, not one per platform. Keep these fields distinct:

• Identity: stable Agent identifier, display name, and the source used to discover it.
• Ownership: creating team, business owner, and current operating owner.
• Purpose: intended task, expected users, and the business process it supports.
• Environment: platform, deployment location, runtime, and whether it is managed, custom-instrumented, or manually registered.
• Dependencies: model, tools, data connections, credentials, and external services.
• Evidence: date last checked, source of the information, monitoring availability, and any unresolved fields.

Do not silently convert missing information into a default. Mark the field unknown, name the person who must resolve it, and restrict consequential use until the gap is understood.

Platform engineering owns discovery coverage and record freshness

Your platform team should prove how an Agent enters the inventory and how a change updates its record. A one-time export is a snapshot, not an operating process. Agents may be created in platform consoles, deployed through application pipelines, or run in custom environments that do not share a common control plane.

For every source, record the discovery method and its limitations. An integration can report only what it exposes and what its permissions allow it to read. A custom environment may require instrumentation and an agreed telemetry schema. A manually registered Agent needs an owner who is responsible for updates when its configuration, tools, or runtime change.

OpenTelemetry’s signal documentation separates telemetry into signal types, which helps you ask what evidence a particular integration actually emits rather than assuming that “monitored” means “fully observable.” OpenTelemetry’s signal concepts A dashboard may show activity while omitting tool arguments, approval decisions, deployment changes, or business outcomes. Confirm those details against your own telemetry and audit records.

Use these acceptance checks before treating discovery as dependable:

• [ ] Match the inventory against deployment manifests, platform records, and known custom runtimes.
• [ ] Record the source and last verification status for each discovered Agent.
• [ ] Identify environments outside stated integrations and assign a manual-registration owner.
• [ ] Confirm what telemetry each integration or instrumentation path actually emits.
• [ ] Define who updates the record after model, tool, data-access, or runtime changes.
• [ ] Set a recurring review trigger based on your change and risk processes, not on an assumed product refresh schedule.

If you cannot explain how a newly deployed Agent becomes visible, your inventory is not complete enough for governance decisions. Keep a separate gap list and assign the engineering work or manual process needed to close each gap.

Business and engineering leads must confirm purpose and accountability

A platform account is not a business owner. The person who created an Agent may have moved teams, built a prototype, or handed it to another group. Record the creating team separately from the team that now operates it and the person accountable for its business use.

Ask the business owner to confirm the intended purpose, users, and expected outcome. Ask the operating owner to confirm who maintains dependencies, responds to failures, and can pause the Agent. If the two answers conflict, keep the Agent in a review state until the responsible teams agree.

This distinction matters when the original use changes. An internal summarization Agent may later be connected to a customer workflow; a research prototype may acquire access to a production data source. The name and creator can remain the same while the consequences change. Treat changes in audience, data, and available actions as reasons to reassess ownership and risk.

For each record, require a clear answer to three operational questions: who approves continued use, who can disable the Agent, and who investigates an unexpected action? If nobody can answer, do not let the platform owner’s account stand in for business accountability.

Security teams should rank risk by impact and evidence

Risk priority should reflect what the Agent can do, what it can access, and what could happen if it behaves incorrectly. Start with Agents that face customers, handle sensitive data, or can execute transactions. Then consider breadth of tool access, ability to create external side effects, the presence of human approval, and how easily an action can be reversed.

Write down the evidence behind each rating. A label such as “high risk” is not useful unless reviewers can see the underlying data access, tools, actions, and approval conditions. Dataiku describes risk management as part of Agent Management, but your internal classification rules remain your organization’s responsibility. A vendor category is a triage input, not a security certification.

Use established risk guidance to structure your review rather than to outsource the decision. The NIST Generative AI Risk Management Framework profile provides risk-management context for generative AI. The OWASP Agent Security Cheat Sheet offers security considerations for Agent systems. Neither document certifies a specific deployment as safe.

For each higher-impact Agent, document:

• The data it can read or change, including sensitive or regulated sources.
• The tools and external services it can call.
• Any action with a real-world side effect, such as sending, purchasing, or changing records.
• Where a human must approve an action, and what happens if approval is unavailable.
• The evidence used to assign risk and the person responsible for reviewing it.

If the evidence is incomplete, state the operational response. That may mean disabling a consequential tool, limiting the Agent to test data, requiring a human approval step, or pausing the workflow while the team completes testing. Avoid “approved with unknowns” when those unknowns affect customer data or irreversible actions.

Operations teams must separate monitoring from delivery acceptance

Monitoring is useful for seeing reported health, activity, cost, quality indicators, or behavioral changes when the relevant data is available. It is not proof that a business result is correct. Nor does a healthy status establish that code passed tests, an action stayed within its authorization, or a task was safely delivered.

Assign a source to every operational claim. For example, identify whether health status comes from a runtime signal, usage from platform telemetry, cost from billing records, and quality from an evaluation or human review. Record missing sources explicitly. If monitoring stops, specify who checks the Agent manually, how they detect a failed workflow, and who can suspend it.

Dataiku’s materials describe operational monitoring and risk records; they do not establish that those records cover every business outcome or substitute for your own delivery checks. The product blog’s description of Agent Management should therefore be read as a statement of product intent and scope, not as independent validation of your environment.

Keep these acceptance questions separate:

• Did the Agent run and report expected operational signals?
• Did the output meet the business requirement?
• Did the Agent stay within its permitted data and tool boundaries?
• Was the resulting change tested and approved before delivery?
• Can you connect the evidence to the Agent version or configuration that produced it?

If your monitoring can show that an Agent acted but cannot connect the activity to the deployed configuration, preserve that as an audit gap. Do not use an activity record as evidence of safe release.

FAQ: preparing enterprise Agent governance

What information should be ready before the product opens?

Create a record that captures identity, owner, purpose, runtime, dependencies, data access, tools, evidence source, and verification status. Add an explicit field for unresolved information. This lets platform teams compare product discovery against known deployments without assuming that the product’s announced coverage includes every custom or newly deployed Agent.

How do teams keep ownership consistent across platforms?

Keep a common inventory schema and distinguish the creator from the current business and operating owners. Ask the business owner to confirm the purpose and users; ask the operator to confirm maintenance and shutdown responsibility. When those roles are unclear, mark the record for confirmation rather than assigning accountability based on a platform account.

Which Agents need early review and certification evidence?

Prioritize Agents with customer exposure, sensitive-data access, transaction capabilities, broad tool permissions, or unclear human approval boundaries. Keep the organization’s risk rationale, tests, reviewer, and review status with the record. A vendor’s risk label may help route work, but it does not replace your policies or certify that a deployment is safe.

Do monitoring records provide execution control?

No. Monitoring can expose activity and changes only to the extent that integrations and instrumentation supply those signals. Permission enforcement, process isolation, identity restrictions, and human approval must be implemented and tested in the relevant execution and access layers. A missing signal should trigger a defined manual response; it should never be treated as evidence that no risky action occurred.

Governance leads must preserve review and change evidence

A high-risk Agent needs more than a status label. Keep its risk rationale, test evidence, approval state, reviewer, and next review responsibility together. Make sure a reviewer can tell which Agent version or configuration the evidence covers. If a model, tool, permission, data source, or execution environment changes, decide whether the previous review still applies.

NIST’s AI RMF Playbook offers guidance for organizing risk-management actions. Use it to improve the review process, but keep the actual acceptance criteria specific to your workflows. For example, a review of a read-only research assistant does not demonstrate that a transaction-capable Agent has safe approval controls.

Set a response for each evidence gap before it becomes a production incident:

• Pause when a consequential action has no accountable owner or acceptable review evidence.
• Restrict access, tools, or users when the Agent can be tested safely with a narrower scope.
• Retest when a configuration or dependency change invalidates earlier evidence.
• Continue with documented limits only when the remaining risk is understood and accepted by the responsible owner.

These are operational decisions, not product settings. A monitoring platform may help teams find records or observe reported behavior, but it does not decide who accepts business risk.

FinOps and technical leaders should govern from one review queue

Usage, cost, business value, and risk belong in the same decision conversation. An Agent with unclear cost attribution may need better metering before expansion. An Agent with low usage but consequential permissions may still need an urgent security review. An expensive Agent with demonstrated value may deserve optimization rather than immediate shutdown.

Do not estimate savings, product pricing, or required execution capacity from a vendor’s feature description. Dataiku’s announcement discusses its product scope and metering approach, but your enterprise cost depends on your own workloads, integrations, and usage. Confirm commercial terms with the official product information when available, then compare them against observed task volume and operational effort. Do not infer a quote or capacity plan from a general product announcement.

A useful review queue combines:

• Ownership gaps: no confirmed business owner or operator.
• Risk gaps: high-impact access without a documented review or approval boundary.
• Evidence gaps: monitoring, tests, or configuration history cannot support the claim being made.
• Cost gaps: usage cannot be tied to an Agent, task, or business purpose.
• Value gaps: no agreed outcome or usage evidence justifies continued operation.

Resolve ownership and high-impact evidence gaps before optimizing low-risk workloads. That ordering prevents a cost dashboard from making an unreviewed Agent look acceptable simply because it is cheap.

Choose execution environments by control requirements

Visibility and execution control solve different problems. An inventory tells you what you know about an Agent. Monitoring can show signals your environment collects. Neither one isolates code, limits credentials, or prevents a tool from reaching a system. Check the actual runtime controls: identity, network access, secret handling, data scope, approval gates, and the ability to stop execution.

Use this decision rule:

• If the Agent only needs to report activity, verify its telemetry path and assign an owner for missing signals.
• If it handles sensitive data, require evidence for access restrictions and data boundaries.
• If it can take consequential actions, test permission limits, approval behavior, and interruption paths before broadening use.
• If your current runtime cannot enforce the boundary you need, move the workload to an environment that can—or pause the risky action.

The execution environment is part of the Agent’s risk profile, not a field to fill in after deployment. Record whether the workload runs in a managed platform, a custom instrumented service, or a separate machine, and document which controls apply in that location. A “visible” Agent is not necessarily a controlled Agent.

Turn the inventory into a launch-ready operating process

Before adopting a new management console, make the underlying records useful without it. A product can improve discovery and reporting, but governance still depends on owners who confirm purpose, operators who maintain execution boundaries, and reviewers who connect evidence to changing configurations.

For each Agent, complete the following checks:

• [ ] Confirm the Agent’s identity and the source used to discover it.
• [ ] Name the business owner, current operator, and person authorized to pause it.
• [ ] Record its purpose, intended users, models, tools, data connections, and runtime.
• [ ] Mark whether discovery comes from a stated integration, OpenTelemetry instrumentation, or manual registration.
• [ ] Identify customer exposure, sensitive data, external actions, and human approval boundaries.
• [ ] Assign a risk level using your own criteria and preserve the evidence behind it.
• [ ] Connect health, usage, cost, quality, and behavior claims to their actual evidence sources.
• [ ] Link review and test evidence to the configuration or version it covers.
• [ ] Define what to restrict, retest, or pause when evidence is missing or a boundary changes.
• [ ] Assign a review owner and a trigger for updating the record.

For teams relying on existing shared runners or general-purpose cloud environments, the weak points are often unclear ownership, shared credentials, and runtime boundaries that are hard to prove. Moving everything to a Mac is not a universal fix; your existing environment may be the right choice for steady workloads, specialized interfaces, or non-macOS dependencies. But when an Agent must build, test, or deliver through a real macOS toolchain, a rented Mac from vmzig can provide a separate environment to validate that workflow without making a personal workstation the default runner. Start with the deployment and isolation requirements in your inventory, then choose the environment that can demonstrate the controls you need.

FAQ

What should we record before Dataiku Agent Management is available?

Record each Agent’s stable identifier, business purpose, owning team, operating owner, model and tool dependencies, data connections, deployment environment, and source of each fact. Mark when the information was checked and whether it came from an integration, a configuration record, or a human confirmation. Keep unknown fields visible; do not treat an incomplete record as approval.

How can teams register Agents across platforms without losing ownership?

Use one inventory schema even when discovery comes from different platforms. Separate the team that created an Agent from the person or team responsible for its current operation. Ask each business owner to confirm the purpose and audience, then ask platform operators to confirm the runtime and dependencies. Escalate records with no accountable owner instead of assigning ownership to whichever account created them.

Which enterprise Agents should go through risk review first?

Start with Agents that face customers, access sensitive information, or can trigger transactions and other consequential actions. Then review Agents with broad tool access, weak approval boundaries, or unclear ownership. Your organization must set the actual risk criteria and required evidence. A vendor’s risk label can inform triage, but it is not a security certification or a substitute for your own review.

Can Agent monitoring replace permission controls or an isolated execution environment?

No. Monitoring can help you see reported activity, usage, or changes in behavior, depending on the available signals and integrations. It does not itself restrict a tool call, prevent access to data, or isolate a process. Enforce those boundaries in the runtime, identity, network, and approval layers, and test that the controls still hold when monitoring is delayed or unavailable.