When an AI Agent Joins the Operation

This article continues the path from The Cooling Alarm Is Only the Beginning and One Asset, Four Identities. The first article followed a decision across facilities, hardware, Kubernetes and business systems. The second stopped at the identity problem hidden inside that decision. Now I want to change the consumer: instead of an operator assembling the context, an AI agent is asked to help.

Consider a short request:

Can we drain worker-a17 now? If we can, prepare the action and explain what will be affected.

The agent needs current workload placement, disruption constraints, the physical server behind the node, active maintenance and perhaps service ownership. It also needs to know which of those facts the caller is allowed to see and whether the caller can prepare, approve or execute the change.

Giving the agent a set of tools makes the systems reachable. It does not establish what their records mean together, which relationships are trusted or whose authority the agent is exercising. If each tool also arrives with a powerful credential, the agent quietly becomes a new integration and security domain. The boundaries created by that decision are the part of operational AI that interests me most.

The prompt arrives too late to define the operation

We can describe a great deal inside a prompt: which sources exist, how a server relates to a node, which fields identify an asset and what conditions make a drain acceptable. We can ask the model to infer anything we did not describe. The weakness becomes visible when the next task describes the operation differently.

An identity relationship inferred for one conversation may not be chosen in the next. A tool description may say that a field contains a hostname without explaining its scope or lifecycle. A maintenance API can expose an assetId, but access to the API does not prove that the identifier corresponds to the Redfish ComputerSystem currently reporting a fault.

I would rather make those decisions before the prompt arrives. The agent should discover a bounded model with known entities, identities, relationships and available operations. Reasoning still has a role: it can decide which parts of the model matter, form a query and evaluate the returned state. It should not have to invent the basic shape of the operation every time it is asked a question.

This does not require a complete enterprise ontology. The cooling case needs a much smaller model: cooling zone, rack, chassis, Kubernetes node, workload, service and maintenance window. If another decision requires energy pricing or spare-parts inventory, that part can be connected later. What matters here is that the model exists independently of the agent using it.

The agent needs an identity before it needs data

The authorization question is easy to hide during a demonstration because the agent usually runs with a token prepared by the developer.

In a real operation, we need to decide whether the agent is acting on behalf of a person or operating as a service in its own right. Both are legitimate, but they are not interchangeable.

An agent working inside an interactive session may receive delegated authority from the caller. A monitoring or remediation agent may use a service identity with permissions defined for that purpose. In either case, the identity and its roles should come from the organization's IAM process. The agent should not grant itself access by choosing a connector or by copying credentials from a tool configuration.

Kubling deliberately does not implement another internal IAM. It delegates authentication and role retrieval to an external identity system, then maps those roles to Data Roles defined for a Virtual Database. Those permissions can govern CRUD operations at schema, table and column level. The authenticated session carries that security context, and the Engine applies it when executing the request. The RBAC documentation describes the current mechanism and its boundary.

This gives agents and conventional applications the same authorization entry point. It does not mean that Kubling automatically propagates the caller's identity into every source. A provider may connect to its source using credentials configured for that integration. Kubling remains responsible for deciding what the authenticated consumer can request through the federated model.

That distinction prevents a convenient phrase such as “inherit the user's access” from turning into uncontrolled token forwarding.

Avoiding a parallel authorization plane

When every agent tool owns a separate credential and permission model, the organization has created a parallel authorization plane.

Access may still be restricted, but the rules no longer follow the same path as other operational clients. Removing a user from an IAM group may not remove a permission embedded in an agent tool. A service account created for a prototype can outlive the prototype. Two tools may expose different portions of what is conceptually the same asset because their credentials were provisioned independently.

Centralizing identity and role assignment does not require centralizing the data. A Kubling instance can remain near a site or group of sources while accepting identities and roles governed by the organization's IAM. Higher-level Kubling instances can compose those models without turning the agent into the owner of source credentials or access rules. This leaves the topology distributed while keeping authorization in a path the security team already understands.

Authorization should shape the context

Rejecting an unauthorized query at execution time is necessary, but an agent-facing model introduces an earlier concern.

If an agent receives a catalog containing every entity and relationship, it has already learned something about resources outside its scope. It may repeatedly plan queries that the Engine will reject. Worse, a generated prompt can contain names or descriptions that the current identity should never have received.

The context presented to the agent should therefore be derived from the same authorization boundary that will govern execution. A role that cannot read a customer column should not discover it through an agent context response. An identity that can inspect a maintenance window but cannot update it should see that difference before proposing an action.

The important property here is larger than RBAC. Kubling applies one authentication and authorization path across the different ways in which it exposes data and operations. At ingress, Kubling authenticates the request through the configured delegate and establishes the effective identity and roles. From that point on, the same security context accompanies the query or operation. A client transport, an authenticated Script Endpoint and an internal query do not need separate security models around them.

Take a Script Endpoint that receives an authenticated request and uses DBEngine to run a query. That query is authorized with the request's effective identity and roles, so the endpoint author does not have to rebuild authorization around the database call.

The capabilities path coming in Kubling 26.5 extends the same mechanism to agents. The Engine captures the effective caller at ingress, derives the catalog and semantic context that caller may receive, and preserves the caller when a proposed action reaches execution. Credentials used to communicate with an agent runtime cannot replace that identity or broaden its permissions. The model sees a useful slice of the operation, but Kubling still owns the upper bound of what can be disclosed and executed.

A model connected to live state

An explicit model is useful only if the operational question can reach the state it describes.

For analytics, a copied dataset may be exactly what we want. It gives us a stable historical record, supports expensive transformations and makes broad aggregation practical. An operational decision has a different relationship with time and authority.

The model may say that a Kubernetes Node runs on a particular chassis. The answer to “can we drain it now?” still depends on current pods, disruption budgets, hardware state and maintenance activity. Embedding yesterday's values in an agent index gives the model context, but not necessarily the operation as it exists when the decision is made.

Kubling queries source-owned data directly and lets the Engine plan work across providers. This removes a copy pipeline as a prerequisite; it does not promise impossible instantaneous consistency. A slow provider remains slow. A source can be unavailable. Two systems can observe related state at slightly different moments. Those boundaries should be visible in the result and its traces rather than hidden behind the word real-time.

I think of the explicit model as the stable coordinate system and the providers as its connection to current reality. Without the model, the agent has to reconstruct meaning from live feeds. If the model is populated from an old snapshot, it can describe an operation that no longer exists.

One security context across every entry point

The flow is better represented with the authentication boundary inside Kubling rather than as a direct chain from IAM to source:

flowchart TB
  caller[Operator, application or agent]

  subgraph kubling[Kubling Engine]
    entry[Client transport, Script Endpoint or capability endpoint]
    entry --> auth[Authentication and authorization boundary]
    auth --> session[Effective caller and session roles]
    session --> policy[VDB Data Roles]
    policy --> execution[Federated query and operation execution]
    policy -->|capability path| context[Caller-authorized capability context]
    context --> runtime[Replaceable agent runtime]
    runtime -->|structured request| execution
  end

  caller --> entry
  auth <-->|validate credentials and return roles| delegate[Authentication delegate]
  delegate <--> iam[External IAM]
  execution --> providers[Providers]
  providers --> redfish[Redfish]
  providers --> kubernetes[Kubernetes]
  providers --> api[Operational API]

The request reaches Kubling before the external IAM participates. Kubling invokes the configured authentication delegate, obtains the effective identity and roles, then applies the VDB's Data Roles inside the Engine. Providers may still use integration credentials to reach their systems; the caller's token is not passed indiscriminately from one source to the next.

The same session and authorization rules apply across the Engine's client transports, and an authenticated Script Endpoint keeps them when it performs internal work. The capability branch adds an authorization-filtered model for the agent runtime, then sends its structured request back through Engine-owned execution. The RBAC, Script Endpoint and transport documentation describe the public parts of this mechanism.

The diagram is intentionally missing an LLM vendor. That choice belongs outside the operational authority boundary and should remain replaceable. Kubling owns resolution, authorization, planning and execution. The agent proposes a structured request and interprets the result. A provider translates the planned work to the source it understands.

This is close to why Kubling exists

Kubling did not begin with an LLM. It began with a recurring systems problem: useful operational questions cross boundaries, while the data, protocols, ownership and permissions remain distributed.

The original response was federation. Expose the source models, make them queryable together, keep the sources authoritative and avoid requiring a new central data platform before the first useful decision can be made. IAM integration and Data Roles were necessary because a common query surface without a common authorization boundary would only move the fragmentation elsewhere.

AI agents make the consequences of those decisions easier to see. A human operator can compensate for an implicit relationship, remember which account is permitted to access a system and notice that a value looks stale. An agent will only have the boundaries we provide. Adding more tools increases reach; it does not automatically add the operational knowledge and authority that experienced people carry between systems.

This is why I see agents as a new consumer of Kubling rather than the center of Kubling. The Engine remains the stable entry point even if the agent runtime or model provider changes.

Could this be done with five MCP servers?

Sometimes, yes. MCP gives an agent a standard way to discover and invoke tools or resources, and its HTTP authorization model gives each protected server a well-defined security boundary. If the task is naturally split into five independent operations, five MCP servers may be a very sensible design.

The difficult case is the request that crosses all five. MCP deliberately does not define that a Kubernetes Node, a Redfish ComputerSystem and a maintenance record represent the same operational asset. It does not supply a shared federated query planner or decide which combined view is valid for the current caller. Those are application and system-design responsibilities around the protocol.

It is possible to implement them across several MCP servers, but then someone has to own the relationships, reconcile their schemas, coordinate identity and source credentials, handle partial failures and prevent each tool from becoming its own policy island. The complexity does not disappear because the tool interface is standard.

This is the practical reason for putting Kubling in the operational path. Kubling resolves those systems into one federated model, applies one Engine-owned identity and authorization boundary and executes against the sources that still own the live state. MCP can remain an excellent interface between an agent host and that boundary. It does not have to become the place where the operational model is rebuilt.

What is coming in Kubling 26.5

Kubling 26.5 will make the capability path much more concrete. Its new capabilities schema gives the Engine ownership of the task boundary: ingress binds the effective caller, context is derived from the model that caller may access, the runtime returns structured requests, and Kubling authorizes and executes them with explicit limits.

This is a much stronger base than the previous capabilities version. That earlier work produced some interesting results and, just as importantly, showed us where the contract needed to be tighter. I will share those results and the design changes in a separate post once the 26.5 artifacts are ready to inspect.

An operational agent should enter through the same identity, model and execution boundaries as every other trusted client. We should be able to replace the language model without redesigning source access, permissions or the meaning of the operation. That is probably the clearest test of where each responsibility belongs.