Sovereign AI

The Bottom Line

Agents should not treat a visible tool as permission to use it. They should request a capability from an authorized executor, receive only the outcome their task needs, and bind that outcome to a durable decision record before any consequential action proceeds.

That change separates three concerns that a direct tool call often collapses: access to evidence, authority to execute, and knowledge of the outcome. A direct call can be appropriate for a local, read-only calculation. It becomes difficult to govern when an agent can reach systems holding sensitive data or can initiate an external effect.

The proposed pattern is called capability-mediated delegation. A requesting agent publishes a typed question. A separate agent or service that holds the necessary authority evaluates it inside its own boundary. It returns a constrained response rather than the underlying records. Kafka carries the messages, while a decision record links the evidence, policy, response, and later effect.

This is an architectural proposal, not a Kafka or MCP standard. The layers have separate security boundaries. Kafka ACLs govern a principal's access to broker resources such as topics and consumer groups. Transport authorization governs access to a protected resource over its transport. Executor policy decides whether a requested business capability may be performed in a particular case. Business approval records the required human or accountable-system decision when policy calls for one. Decision records preserve the basis and outcome for later audit; they do not grant access. Kafka documents authentication and ACL-based resource control as distinct cluster controls, while the MCP authorization specification defines authorization for HTTP-based protected resources.

The central question is therefore not, “Can the model call this tool?” It is, “Who may perform this capability under the policy that applies now, and what may the requester retain afterward?”

‍

A tool registry can create an unexamined trust path

A tool map is useful for discovery. It is a poor substitute for authority.

When an agent sees a tool definition, the interface usually describes an operation and its arguments. It does not necessarily express whether the caller should receive the underlying record, whether the operation is permitted for this case, or whether the resulting action can be reconstructed after a retry. Those questions may be handled elsewhere. The danger appears when they are not.

Model Context Protocol illustrates the distinction. MCP is a standard for connecting AI applications to external systems, including tools and data sources, as described in Anthropic's original announcement. Its authorization material treats protected-resource access as a separate concern. The current security guidance requires token audience validation and recommends short-lived tokens where appropriate. MCP's security considerations protect a transport and resource boundary. They do not define the business authority for a particular agent decision.

A shared registry can therefore create an implicit trust path when independent authorization is absent. The requesting agent may have enough connectivity to ask for information that it should never retain, or to invoke an operation whose business conditions have not been evaluated.

The remedy is not to ban tools. It is to move the authorization decision closer to the executor and make the requested outcome explicit.

‍

Asking for work is different from invoking an implementation

A capability request states the work required without granting the requester direct access to the implementation. “Check whether this spend fits the current approval envelope” is a capability. “Query the finance ledger using these credentials” is an implementation instruction.

That difference permits a narrower contract. The requester can name an intent, supply case-specific arguments, demand a response shape, and set an expiry. The executor can apply its own authorization rules and use systems the requester cannot access. If no eligible executor accepts the request before the deadline, the workflow stops or routes to a defined review path. It must not silently fall back to a broader direct call.

Capability-mediated delegation is an architectural pattern in which a requester asks an authorized boundary to perform a named operation and receives a limited result. It does not receive the credentials or data needed to perform that operation itself. The pattern needs explicit policy, workload identities, schemas, and failure behavior. That is useful pressure: it requires an organization to state what authority means.

Consider a planning process that needs an answer about a proposed expenditure. The planning agent does not need the ledger, supplier history, or reserve calculations. It needs a decision within a stated scope. A finance-bound executor can evaluate the request and return an answer with a limit, currency, validity window, and reason code. The response reveals less than the source system while remaining useful to the next step.

A “yes” is not an approval for every later use. It is a decision with a scope and expiry. This prevents an old response from becoming a standing credential.

‍

‍

The wire contract should express authority and exposure

Kafka is a suitable transport for this pattern because it provides topic-based event streams between independent producers and consumers. It does not prescribe an agent protocol. The protocol must make the security boundaries visible. Kafka's documentation describes the platform's event-stream model and its topic-based organization.

A practical topology uses distinct request, response, audit, and decision topics. Topic names alone do not secure anything. A broker identity and ACL policy must restrict producers and consumers, and application-level policy must validate request content. Kafka's topic-management guidance describes how applications can manage explicit topics; it does not turn those topics into business authorization.

The following envelope is a proposed contract, not a universal schema:

{
  "message_type": "capability.request.v1",
  "correlation_id": "01J9C4M8Q2N7",
  "capability": "budget.check",
  "intent": "determine_commitment_capacity",
  "subject": {
    "case_id": "site-expansion-482",
    "scope": "clinical.sites/2026-Q4"
  },
  "arguments": {
    "amount": 480000,
    "currency": "EUR"
  },
  "response_contract": "decision.limit.v1",
  "required_assurance": "finance-authorized",
  "expires_at": "2026-10-08T12:30:00Z",
  "reply_topic": "planning.response.budget.check"
}

The message does not carry a reusable tool credential. Authentication should rely on transport controls and workload identity. If an application introduces a per-request authorization artifact, it should bind that artifact to a specific audience, request, scope, and short validity period. It should never be logged in plaintext. A credential replayable against a different service or after expiry defeats the boundary the protocol is intended to establish.

Correlation is the hinge. The same correlation_id should connect request, policy evaluation, response, approval, attempted effect, and final outcome. Without that chain, an audit can show that events existed but cannot reliably answer which decision led to which action.

‍

A constrained answer keeps the source boundary intact

The response contract should describe what the requester may know, rather than merely what the executor happened to return.

For the expenditure example, an executor can return the decision and its bounds:

{
  "message_type": "capability.response.v1",
  "correlation_id": "01J9C4M8Q2N7",
  "capability": "budget.check",
  "decision": "allow",
  "limit": 500000,
  "currency": "EUR",
  "scope": "clinical.sites/2026-Q4",
  "reason_code": "within_quarterly_envelope",
  "exposure": "decision_only",
  "policy_version": "budget-policy-2026-10-01",
  "valid_until": "2026-10-15T00:00:00Z"
}

The requester can decide whether the proposed amount fits the declared limit. It cannot infer the wider ledger from the response. That outcome restriction is a policy objective, not a guarantee supplied by JSON. The executor must avoid embedding sensitive explanation in free text, and the requesting agent's context and logs need retention controls of their own.

The response should also be typed tightly enough to reject accidental oversharing. A schema that allows an unbounded details field will eventually carry material that was never intended to cross the boundary. Keep diagnostic data in an executor-controlled audit location, or expose it through a separate capability with stronger authorization.

A response can be a refusal. It should use the same correlation and provide a machine-readable reason where safe. “No authorized executor,” “expired request,” and “policy condition not met” are operationally different outcomes. Treating each as a vague model message creates ambiguity precisely where the system needs control.

‍

Can AI agents act without sharing tool access?

Yes. An agent can act through delegated capabilities without holding direct access to every underlying tool, but this requires a routable executor, explicit policy, and a response contract.

The executor may be another agent, a deterministic service, or a workflow worker. The important property is that it owns the connection to the protected system and evaluates requests at that boundary. The requester receives a decision or bounded artifact, not a hidden tool handle.

This structure creates useful separation, but it also adds coordination work. The requester must know how to ask for a capability. The runtime must select an eligible executor. The executor must handle duplicate delivery, expiration, and changing policy. Each part requires a defined rule.

KafClaw publicly describes itself as a self-hosted, Apache 2.0 multi-agent runtime on Apache Kafka. Its documented wire model includes typed JSON envelopes, Kafka topics, correlation IDs, trace spans, shared memory, and distributed skill routing. Those published runtime features can carry the proposed protocol in this article. They do not themselves define the executor policy, approval rule, or business authority described here.

‍

The decision record is the object worth preserving

Message retention is valuable, but a series of messages is not automatically a coherent decision record. A later reviewer needs more than a request and a response. They need to establish the evidence used, the policy version evaluated, the person or system that approved any escalation, the effect attempted, and whether that effect completed.

No supplied public source establishes a completed KafGraph decision-record proof artifact containing all of those fields. The following is therefore a proposed design sketch, rather than a claim about an implemented KafGraph capability. The Scalytics open-source page identifies KafGraph among its open-source tools, but a graph-shaped record must still be designed, populated, retained, and governed.

For the expenditure case, one proposed record would trace the path as follows. The source event is planning.requested at a recorded topic, partition, and offset. The evidence reference points to the executor-controlled ledger snapshot or query result, with a content hash and retention reference rather than the ledger contents. The graph relation joins the case, request, evidence reference, and policy evaluation. The policy result names budget-policy-2026-10-01 and records allow with the limit. The selected action is create_commitment_hold. An approval field records either that no approval was required or the approving identity and time. The effect records a stable idempotency key and the downstream result. The outcome records completed, failed, or unknown. Replay reads those immutable references and state transitions to explain the decision; it must not replay the external effect.

This design distinguishes a graph from a transcript. Relationships can make the record easier to query, but a graph does not prove that the source was reliable, that a policy was appropriate, or that a model conclusion was justified. It preserves the material needed to test those questions. The Scalytics analysis of Kafka and MCP similarly argues that data access and conversation history do not establish transactional authority or a durable audit record.

A Sovereign Decision Fabric is described by Scalytics as a Kafka-native platform where business-relevant events are observable, agents and policies reason where data is produced, and decisions are written as immutable, auditable events. That published definition provides architecture context. It should not be read as proof that every deployment has the proposed record schema, graph relationships, or approval workflow in this article.

‍

The request path needs idempotency before it needs autonomy

A correct decision can still produce an incorrect external result when delivery fails at the wrong moment.

Suppose an executor accepts an instruction to create a downstream hold. It sends the request, then loses its process before recording the response. A retry is reasonable from the requester's perspective. The downstream service may see a second operation. If the operation is not idempotent, a valid decision has now created duplicate effects.

The answer is not to avoid retries. Distributed systems cannot assume a response arrives after every successful external call. Instead, bind an idempotency key to the intended effect and record the state transitions around it. The executor should determine whether the effect with this key has already completed before invoking the downstream system again.

A minimal decision state machine can make the rule inspectable:

1. Receive and validate the capability request.
2. Evaluate the current policy and write the decision state.
3. Obtain approval when the policy requires it.
4. Attempt the external effect with a stable idempotency key.
5. Record whether the effect completed, failed, or remains unknown.
6. Reconcile unknown outcomes before allowing a new attempt.

This sequence does not make every downstream system idempotent. It identifies systems that cannot safely participate without a compensating control. That is an early architectural finding, not an inconvenience to conceal.

‍

Where this pattern adds cost and where it is the wrong choice

Capability-mediated delegation introduces latency, operational complexity, and schema governance. It creates more messages, more identities, more policy versions, and more failure states than a local function call. The pattern is a poor fit for a computation that is genuinely local, read-only, and non-sensitive, especially when data and output have the same access boundary.

It is also not a replacement for a proper authorization system. Kafka ACLs, network segmentation, workload identity, and protected-resource authorization remain necessary. The delegation layer adds business semantics above those controls. If the underlying executor is broadly privileged and poorly monitored, wrapping it in agent messages changes little.

A graph record does not solve evidence quality either. It can faithfully preserve a bad source, an outdated policy, or an unjustified model conclusion. Reviewers still need to determine whether the evidence was sufficient and the policy appropriate. Durable provenance makes that examination possible. It does not make it unnecessary.

Finally, this approach should not be presented as a generic alternative to all tool use. Some operations need a human approval path. Others should remain unavailable to autonomous agents. The policy can express both outcomes, but the organization has to decide them first.

‍

Authority should travel with the decision not the tool map

The practical design choice is to identify the capability boundary before connecting another tool. Ask what information the requester needs, who is allowed to produce it, what policy applies, how long the response remains valid, and how a later reviewer will reconstruct the effect.

If those answers cannot be written into a request, response, and decision record, the autonomy is underspecified. More model capability will not fix that.

For systems where reasoning must remain close to source data, Scalytics open-source tools provide publicly described components for a Kafka-native approach. Schedule an architecture review to map capability boundaries, decision records, and failure paths before those boundaries become production incidents.