The Agentic Infrastructure Pivot: CIQ, MariaDB, and Harness Just Redefined Who Their Platform Is For

The first week of November 2026 produced three announcements that, on their own, look like ordinary vendor news. Put side by side, they are one architectural event: CIQ, MariaDB, and Harness each redesigned their platform's control surface for a customer that is not human. On October 29, CIQ introduced Stratum Kubernetes Engine — an open-source Kubernetes distribution whose single signed binary ships with a Model Context Protocol server baked into the engine. On November 3, MariaDB announced Enterprise Platform 2027 and rebranded itself "the Unified Open Database Platform for the Agentic Enterprise." On November 5, Harness published We Rebuilt Harness for Agents and rolled out an early-access platform experience in which its entire product catalog is now agent-named: Software Delivery Agent, Security Testing Agent, Runtime Protection Agent, Cost Management Agent.

This is not the "AI features" wave of 2025, where vendors stapled a chatbot onto a console. What shipped this week is the boring, load-bearing part: typed tool surfaces, permission tiers a human sets once, refusal lists for self-promotion paths, memory as a platform service, and documentation written for machines. Harness's framing is the sharpest of the three: "A year ago, the question was whether agents could write code. That question is settled. The new question is whether they can ship it."

Methodology, honestly stated: everything below was verified against the vendors' own primary sources — CIQ's published documentation (including its full llms-full.txt corpus), MariaDB's press release and engineering blog, the Harness platform post, and the Harness and MariaDB MCP server repositories. We did not run these platforms hands-on for this piece, and we flag every claim we could not trace to a primary source. Where press releases and documentation disagree, you get both, verbatim.

The Structural Shift: The Customer Changed

Every platform market has a moment where the buyer stops being the person typing the commands. Databases went through it when ORMs arrived; clouds went through it when Terraform arrived. The agent wave is that moment for the entire infrastructure stack, and the tell is that all three vendors this week moved the operator up one level of abstraction — from the person who drives the platform to the person who authors what an agent is allowed to do.

CIQ's CTO Peter Nelson said it directly in the launch interview: a developer can "task the agent with setting it up and be running in minutes, and that agent can only do what the developers allowed it to do." MariaDB's product blog is titled Agents Are the Database's Newest Customer and opens by describing the new arrival precisely: "a new kind of user is showing up at the database, one that writes its own queries at runtime, branches on every result, and rarely travels alone." Harness renamed the products.

The rest of this piece is about the pattern underneath the three announcements, because the pattern — not any single product — is what you will be asked to evaluate, budget for, and govern over the next four quarters. If you run agents against infrastructure at all, read the authentication and authorization design for agent fleets alongside this; the two halves of the problem are now converging on the same wall: the permission boundary.

Primitive 1: A Typed Surface, No Shell Passthrough

The first thing all three vendors removed is the agent's favorite attack vector: the free-form command. CIQ's MCP server documentation is unambiguous: "There is no kubectl passthrough, and no tool takes a free-form command. Every input is a typed field, and the resource to act on is resolved through discovery rather than pasted into an argument list." The server exposes narrow, typed tools — pod_list, pod_get, pod_logs, node_list, event_list, resource_list/resource_get for arbitrary kinds including custom resources, plus Stratum-specific state like cluster_status, which reports the supervisor's intended process table versus what is actually running — something the Kubernetes API cannot see at all.

Harness made the opposite design choice on tool breadth, and its reasoning is worth quoting because it is the best articulation of the tool-count problem we have seen in vendor docs. The open-source Harness MCP Server exposes 11 consolidated tools — harness_describe, harness_schema, harness_list, harness_get, harness_create, harness_update, harness_delete, harness_execute, harness_search, harness_diagnose, harness_status — that dispatch by resource_type across 142 resource types in 30 toolsets. The docs explain why: "Unlike MCP servers that map one tool per API endpoint (which degrades LLM tool-selection accuracy as tool count grows), this server keeps the tool count small and the schema footprint minimal." So you have two poles — CIQ's many narrow typed tools, Harness's few generic verbs plus a registry — and both poles reject the shell.

MariaDB went a step further in the same direction with a detail we have not seen anywhere else: the companion mariadb-guard package in its AI Plugins repository "stops the agent from using the MariaDB command-line clients for what the MCP tools do." The typed path is not just offered; the raw path is actively closed off, because an agent that can fall back to mariadb the CLI will route around mariadb the protocol the first time a tool refuses something. The plugins support Claude Code, Codex, OpenCode, Pi, Cursor — and our own Hermes Agent, which is how we first noticed the repo.

One more CIQ detail belongs in this primitive because it is the most production-aware thing in any of the three launches: every result the MCP server returns is fenced as untrusted data. Pod log lines, events, and annotations "can say anything its author likes, including text written to look like instructions," so each result arrives inside markers of the form <untrusted-data id="...">…</untrusted-data> with a random per-call id, anything resembling a marker is defused first, and the server's instructions tell the client the fenced text is data, never instructions. Structured output (structuredContent) stays parseable for schema-validating clients. That is a prompt-injection control implemented at the tool boundary, which is exactly where it belongs — see our agent security tooling survey for why prompt-injection defense at the harness layer keeps failing in the field.

Primitive 2: Capability Tiers, Decided by a Human at Startup

CIQ's tier design is the most instructive of the three because it is the most opinionated. What the server offers is decided when you start it, not per call:

The flags are independent — --allow-destructive on its own does not enable the write tier. And the load-bearing design decision, quoted verbatim from the docs: "A tool above the tier you enabled is not registered at all. It does not appear in the client's tool list, so the agent never learns it exists. That is deliberate: a tool that appeared and then refused would tell the model the capability is there and invite it to look for another way to the same effect." This is correct agent psychology, and it is the difference between a security model designed by people who have watched an LLM probe a system and one designed by people who have not.

Harness implements the same idea differently: toolset filtering controls which resource definitions load at startup, the write verbs (harness_create, harness_update, harness_delete, harness_execute) request user confirmation through MCP elicitation, risk-based auto-approve exists as a governed dial, and in the new platform experience every versioned step your agent runs is one your team pinned. MariaDB implements it as an allowlist: "The MCP server starts out allowed to reach nothing — installing a plugin wires it up, but does not tell it what it may touch." A one-time mariadb-shell -- mcp setup grants the connection URIs and folders a developer explicitly approves. Three vendors, one principle: capability scope is a startup decision made by a human, not a runtime negotiation made by a model.

Primitive 3: RBAC Is the Only Hard Wall — and Every Vendor Now Says So

The most important sentence in CIQ's MCP documentation is a warning, and it deserves to be pinned in every platform team's runbook:

"Kubernetes RBAC is the only hard boundary. The tiers decide what this server offers; RBAC decides what the credential is actually allowed to do. A server started with no flags but running as cluster-admin is one misconfiguration away from full cluster access, and nothing at the protocol layer can take that back."

CIQ then enumerates the paths by which an agent could promote itself, and refuses all of them regardless of tier: no writing RBAC ("Writing a ClusterRoleBinding is self-promotion to cluster-admin, which would make the tiers meaningless"), no writing admission control — including the CEL-native ValidatingAdmissionPolicy and MutatingAdmissionPolicy objects, no writing Secrets, ServiceAccounts, CSRs or APIServices, no writing Node objects, no installing a CRD with a conversion webhook, no creating PVs/PVCs, no writing HelmChart/HelmChartConfig in a privileged namespace, and no applying pod specs that escape their namespace (hostPath, hostNetwork, hostPID, privileged, added capabilities, unmasked procMount) or that carry Secrets by any route — secret volumes, projected sources, secretKeyRef, envFrom secretRefs, and imagePullSecrets, "which needs no container at all: the kubelet presents the credential to whatever registry the image names." The checks run against any object with a containers list at any depth — Pod specs, workload templates, PodTemplates inside custom resources — and manifests nested more than 64 levels are refused outright. Secrets are refused at every tier even with cluster-admin, because "a Secret's contents in an agent's context window is the worst read this server could perform, and it cannot be taken back."

Harness states the same principle at the platform layer: "Agents do not get a separate rulebook. They run under the same approvals, policies, and audit trail as everyone else." Worker Agents are first-class pipeline steps, so the controls you already put on pipelines govern the agent's work — approval steps keep a human in the loop, OPA policies apply at runtime, and the hosted MCP endpoint runs under the connecting user's own Harness RBAC and permissions. MariaDB applies the database version: a unified role-based access model spans transactional, analytical, and vector workloads, "An agent sees only what the person it works for is allowed to see," and database passwords live in mariadb-shell's secure credential store, never where the agent can read them.

Read those three statements together and you have the actual contract of the agentic pivot: the agent inherits the human's permissions, the platform refuses the paths that would let it escalate, and the audit trail stays intact. If a vendor pitching you "agentic infrastructure" cannot show you all three, they are selling you a chatbot with your cluster credentials.

Primitive 4: Memory Becomes a Platform Service

MariaDB's release is the most architecturally explicit about agent state. Its product blog splits agent context into two kinds: business context — "live, persistent data such as customers and orders, which needs transactions and lives in MariaDB Server, our system of record" — and working context — "its memory, checkpoints and reusable answers, which is short-lived, grows with the number of agents, and lives in MariaDB GridGain, a distributed in-memory key-value and vector store." Keeping the two apart means a burst of agent traffic cannot slow the checkout page, and agent capacity scales without scaling the system of record. Agent Memory checkpoints an agent's progress at every step, keeps extracted state in GridGain rather than the context window (directly attacking context rot and per-step token cost), offers sub-millisecond reads with expiry, and ships integrations with LangChain and LangGraph. Harness now ships the same idea at the platform layer: "Rules and Memories shape how an agent behaves and what it knows. They sit alongside your governance and do not replace it."

The operational significance is easy to miss: memory moved from being something you bolt onto an agent framework to being a durability, residency, and tenancy decision your data platform makes. For teams building long-running or multi-agent workflows, that is the difference between a checkpointing hack and a support contract. Our LLM gateway and router guide covers the request-path half of this problem; MariaDB is betting the other half — durable state — belongs in the database vendor's contract, not your application code.

Primitive 5: Docs and Cost Become Machine-Consumable

The quietest part of the pivot is the one your agents will touch first: documentation. CIQ publishes its full docs in llms.txt format (the complete corpus, llms-full.txt included) and ships an AGENTS.md file to guide agent-driven installs — the same AGENTS.md convention the coding-agent ecosystem standardized on. Harness's docs carry their own llms.txt index and serve markdown on request. MariaDB packages "skills — MariaDB reference material the agent reads when it becomes relevant" as part of its plugins. If your platform's docs are not machine-readable in 2026, the agents your org runs are reading whatever Stack Overflow told them last week.

The second quiet half is cost. MariaDB's Semantic Cache returns stored answers to semantically equivalent questions without an LLM call, using sub-millisecond vector lookups in GridGain. The vendor is admirably careful with the numbers: it cites an AWS study of 63,796 real chatbot queries (up to 86% lower LLM cost and up to 88% lower average latency at a 0.75 similarity threshold, 91% of cached answers judged accurate; 72.5% savings at a stricter 0.9 threshold) and then adds, "Both tested other products, so I would treat them as a guide to what is possible." The threshold tradeoff is the real engineering decision: looser matching saves more and risks answering a question that only looks similar. MariaDB's own candidate list is worth copying into any design doc: FAQs, policy questions, and how-to content cache well; account-specific requests, real-time data such as prices or order status, and anything involving sensitive personal data do not. Harness attacks the same token budget from the other end — its MCP server runs a compact mode that strips verbose metadata from list results, and its Cost Management Agent is now a top-level product. When IDC (cited by MariaDB) projects G2000 agent use growing tenfold by 2027 with token and API call loads rising a thousandfold, token discipline stops being an optimization and becomes capacity planning.

The Architectural Blueprint

Strip away product names and the three launches converge on one topology. The human operator moves to the policy layer; the agent talks to a typed surface whose capabilities were fixed at startup; everything below the surface is governed by permissions the agent inherits, not permissions it negotiates.

        HUMAN OPERATOR (policy author, approver, auditor)
        sets tier flags - allowlists - pinned step versions - OPA rules
                 |                                   |
                 | what MAY be offered               | approvals / elicitation
                 v                                   v
   +-------------------------------------------------------------+
   | CAPABILITY LAYER        (decided at startup, never per-call) |
   |  CIQ:      19 read tools  +8 with --allow-write               |
   |            +11 with --allow-destructive                      |
   |            unregistered = invisible to the model             |
   |  Harness:  11 verbs, toolset filtering, elicitation on write |
   |  MariaDB:  MCP starts allowed to reach NOTHING; allowlist     |
   +------------------------------+------------------------------+
                                  |
                                  v
   +-------------------------------------------------------------+
   | TYPED TOOL SURFACE        (no shell, no free-form commands)  |
   |  CIQ: pod_list/pod_get/pod_logs/resource_get...              |
   |       every result fenced as UNTRUSTED DATA                 |
   |       lists bounded: truncated:true + continuation token     |
   |  Harness: harness_list/get/create/... + resource_type        |
   |  MariaDB: schema read, validated SQL, EXPLAIN, migrations   |
   +------------------------------+------------------------------+
                                  |
                                  v
   +-------------------------------------------------------------+
   | THE ONLY HARD WALL: RBAC / inherited permissions            |
   |  CIQ: dedicated ServiceAccount; Secrets refused at every     |
   |       tier; RBAC writes / admission / node writes refused   |
   |  Harness: agent runs as the user, same approvals + audit     |
   |  MariaDB: agent sees only what its human is allowed to see   |
   +------------------------------+------------------------------+
                                  |
                                  v
        PLATFORM (cluster / pipeline / database)  ->  audit trail

flowchart TB
    A["AI agent proposes action"] --> B{"Tool registered in current tier?"}
    B -- "no: tool invisible" --> X["agent never learns it exists"]
    B -- "yes" --> C{"Typed input passes refusal list?"}
    C -- "no" --> R["refused: RBAC writes, secrets, node writes, escape specs"]
    C -- "yes" --> D{"RBAC on inherited credential allows it?"}
    D -- "no" --> R
    D -- "yes" --> E{"Write / execute verb?"}
    E -- "yes" --> F{"Human approval or elicitation confirmed?"}
    F -- "no" --> R
    F -- "yes" --> G["Platform executes under audit"]
    E -- "no" --> G
    G --> H["Result returned as fenced untrusted data"]
    X -.-> A
    R -.-> A

The Anti-Hype Ledger: Where the PRs Outrun the Docs

We promised you the gaps, and there are several. Some are marketing overshoot; one is a genuine operational warning you would otherwise learn the hard way.

None of these gaps kill the thesis — the tier design, the refusal lists, and the untrusted-data fencing are genuinely good engineering. But the ledger is the difference between buying what was announced and operating what shipped.

The Runnable Bits: Standing Up the CIQ Surface Safely

Of the three, CIQ's surface is the one you can stand up end to end from public documentation today, so it gets the production treatment. The full pattern below is assembled from CIQ's own docs, not our testing — validate in a sandbox before it touches anything you care about.

# One artifact, one command, one node to Ready - no registry access.
# Runs on Enterprise Linux 9+ (amd64 / arm64), cgroup v2 only.
sudo stratum up

# The MCP server ships in the same binary. Default = read-only tier (19 tools):
sudo stratum mcp

# +8 write tools: apply manifests, scale, snapshot, mint join tokens
sudo stratum mcp --allow-write

# +11 destructive tools: upgrade, rollback, rotate CAs, restore etcd, uninstall.
# The flags are independent - --allow-destructive does NOT imply --allow-write.
sudo stratum mcp --allow-write --allow-destructive

# Point the server at a specific cluster instead of the node's admin.conf:
sudo stratum mcp --kubeconfig /path/to/config --context staging

# HTTP transport exists, binds loopback by default, and has NO authentication.
# Never bind it to a routable address without putting auth in front:
sudo stratum mcp --transport http --addr 127.0.0.1:8092

{
  "mcpServers": {
    "stratum": {
      "command": "sudo",
      "args": ["stratum", "mcp"]
    }
  }
}

Now the part that matters more than the tooling: the tier flags are not the boundary. CIQ's docs say it in bold, and the least-privilege configuration they publish is worth copying verbatim — a dedicated ServiceAccount whose role cannot read Secrets and cannot write RBAC:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: stratum-mcp
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: stratum-mcp-read
rules:
  - apiGroups: [""]
    resources: [pods, namespaces, nodes, events, services, configmaps,
                persistentvolumeclaims, persistentvolumes]
    verbs: [get, list, watch]
  - apiGroups: [""]
    resources: [pods/log]
    verbs: [get]
  - apiGroups: [apps]
    resources: [deployments, statefulsets, daemonsets, replicasets]
    verbs: [get, list, watch]
  - apiGroups: [batch]
    resources: [jobs, cronjobs]
    verbs: [get, list, watch]

kubectl auth can-i get secrets --as=system:serviceaccount:kube-system:stratum-mcp
kubectl auth can-i create clusterrolebindings --as=system:serviceaccount:kube-system:stratum-mcp
# Both MUST answer "no". A "yes" to either means the tier flags are the
# only thing standing between an agent and your cluster.

Three operational rules from CIQ's own documentation that belong in your runbook regardless of which platform you pick: first, do not point the server at admin.conf for day-to-day use — it is cluster-admin, and every tier inherits the same unlimited credential. Second, never leave a server running with --allow-destructive: "Starting the server with the flag is the confirmation — it is the equivalent of having typed --yes, decided by a human once rather than by the agent each time." Start one for the operation, watch it, stop it. Third, remember that most destructive-tier tools bypass the server's credential entirely and run on the node's own super-admin.conf — RBAC on the MCP kubeconfig neither enables nor limits them, so the tier flag plus running as root are the only controls. The upgrade_apply tool will only run an upgrade binary an operator staged in /var/lib/stratum/upgrade: a root-owned regular file (never a symlink), verified by sha256 against the copy on every node, "so the model chooses among the binaries you staged and cannot name another program." That is the correct answer to "can the agent run arbitrary code?" — it cannot; it can only choose among things a human put there.

On the Harness side, the governed path is the pipeline, not the API key: Worker Agents run as steps under your existing approval gates, step versions are pinned in the pipeline YAML and constrainable with OPA, and the MCP server's write verbs elicit confirmation. On the MariaDB side, the plugin install and one-time setup are two commands per developer machine:

# Claude Code (Cursor installs the same plugins via its own marketplace):
/plugin marketplace add mariadb/ai-plugins
/plugin install dev@mariadb

# Hermes Agent (companion guard package closes the CLI bypass route):
hermes plugins install mariadb-dev --enable
hermes plugins install mariadb-guard --enable

# One-time setup - the MCP server starts allowed to reach NOTHING;
# this grants the connection URIs and folders a human explicitly approves:
mariadb-shell -- mcp setup

Day-2: What to Watch, and What to Never Do

Metrics that earn their place on a dashboard. Watch truncation, refusal, and error behavior, not just latency: CIQ's bounded lists carry truncated: true plus a continuation token precisely because "an agent handed the first hundred of four thousand pods with no indication will reason about them as though they were all of them" — a truncated list that silently becomes an agent's worldview is an incident generator. Track MCP tool error rates (tool errors surface as protocol errors, not HTTP failures — monitor the tool layer, not just transport 5xx). Track elicitation denials and approval latency on the Harness path: approval gates that humans stop reading are governance theater. And put the two kubectl auth can-i checks above into CI as a regression test — the least-privilege boundary drifts the moment someone "fixes" a blocked workflow by granting the ServiceAccount more rights.

Upgrade-path warnings. CIQ's rolling upgrades drain each node, enforce PodDisruptionBudgets through the eviction API however many nodes drain at once, gate on node health, and roll a node back automatically if a gate fails — controllers go one at a time because "two controllers down at once would cost etcd its quorum." But several security-relevant changes ride the upgrade: admin.conf stops being system:masters (a new root-only super-admin.conf takes that role), kubelets get their own client CA (older clusters must run stratum certs migrate-kubelet-client-ca --cluster --yes or the hardening checks fail), and kube-vip loses its system:masters identity. Translate: after upgrading, your hardening-audit failures are probably telling you the cluster is more locked down than your tooling expects, not less.

Fleet-manager gotchas (Stratum PRO). The commercial tier's SSO has exactly two roles — admin and viewer — and the docs are candid: "Those two roles are the whole authorization model." Sessions last a fixed 12 hours with no flag to shorten, and disabling a user at your identity provider "does not end a session they already hold." Registration tokens are single-use, expire in one hour by default, and the manifest URL 404s once redeemed — good hygiene, but it means your automation must mint tokens per join, not cache them. Cluster provisioning is opt-in twice (a --capi flag plus a separate permissions manifest), speaks Cluster API v1beta1 only, produces clusters whose shape is immutable, and comes up with no CNI — read that as "the convenience features are still early."

Semantic-cache hygiene (MariaDB). Treat the cache-threshold as a data-governance decision: stricter (0.9) trades savings for safety; anything account-specific, real-time, or sensitive must be excluded by policy, not by hope. An agent serving a cached answer to "the wrong person's question that looked similar" is a data-exposure incident with a sub-millisecond lookup at its heart.

Who should skip this wave. Teams with no agents in production: do not stand up any of these surfaces — an MCP server nobody uses is pure attack surface (CIQ's HTTP transport has no authentication at all; the only safe posture is not running it). Teams that cannot staff the policy layer: the entire value of these platforms is the human-authored boundary — tiers, allowlists, pinned versions, OPA — and without someone who owns that, you have added an unattended privilege escalation path, not a productivity tool. Teams needing a supported production Kubernetes distribution this quarter: wait for Stratum's first tagged release, per CIQ's own docs. And teams whose Harness estate is heavily OPA-governed: plan the Rego retest before you opt any pipeline into the new model, because policy that silently stops matching a flatter schema is worse than no policy.

The Verdict

The agentic pivot is real, it shipped, and — unusually for this industry — the engineering underneath the announcements is mostly sound. CIQ's tier-unregistration design and untrusted-data fencing are the most thoughtful agent-safety mechanics we have documented at the infrastructure layer; Harness's "agents do not get a separate rulebook" is the correct governing principle and its registry-dispatch MCP server is a genuinely good answer to tool-count bloat; MariaDB's two-context memory split is the right architecture for agent state and its honesty about borrowed benchmark numbers is refreshing. What remains unproven is the same thing that always remains unproven in week one: whether the tier flags survive contact with real operators who leave --allow-destructive running because the upgrade was due Friday, and whether "early access" platform rebuilds converge before the next rebuild. Evaluate with the ledger above, pilot with read-only tiers, and make the permission boundary — not the model — the thing your design review argues about.

References & Further Reading

• CIQ press release — CIQ introduces CIQ Stratum Kubernetes Engine (Oct 29, 2026) — the 37-tool/tier announcement, AGENTS.md and llms.txt claims, availability timeline.
• CIQ Stratum documentation — MCP Server — the primary source for every tier, refusal-list, and fencing claim in this piece, including the least-privilege YAML.
• CIQ Stratum documentation — Stratum Kubernetes Engine — the single-binary artifact, component versions, pre-release warning, and PRO/engine split.
• Cloud Native Now — Kubernetes For AI: CIQ Packages The Moving Parts Into One Binary (Nov 2, 2026) — the Nelson interview and GA framing this piece checks against the docs.
• MariaDB press release — MariaDB Launches into the Agentic Era (Nov 4, 2026) — platform composition, 56%/25% throughput figures, IDC projections, rebrand.
• MariaDB blog — Agents Are the Database's Newest Customer (Nov 4, 2026) — the two-context model, semantic-cache thresholds, AWS/Regmi study citations.
• MariaDB AI Plugins (GitHub) — the open-source skills + MCP server, mariadb-guard, per-harness install commands.
• Harness blog — We Rebuilt Harness for Agents: Introducing a New Platform Experience (Nov 5, 2026) — one pipeline model, Go Delegate, versioned templates, governed agents.
• Harness documentation — Harness MCP Server — the 11-tool/142-resource-type registry design, elicitation, hosted OAuth constraints.
• Harness MCP Server (GitHub) — the open-source server behind the platform surface.
• Model Context Protocol — the protocol all three vendors built their agent surfaces on.
• AGENTS.md — the convention CIQ adopted for agent-driven install guidance.
• Internal: agent fleet authentication and authorization design, Port's agentic SDLC review, and running AI agents on Kubernetes for the surrounding architecture.