As AI moves from chat to work, enterprises need more than model wrappers, tool connectors, and policy prompts. They need a runtime that decides what an agent is allowed to see, use, remember, approve, and execute before work touches company systems. That is why we are building Tandem.

Every impressive agent demo has the same magic moment. A user asks for something messy: investigate an issue, prepare a compliance brief, update a customer record, triage a pull request, reconcile data across tools. The agent reads context, plans, calls a tool, writes an artifact, calls another tool, and moves the work forward.

Then the enterprise questions begin. Who gave the agent authority to do that? Which tools was it allowed to discover, and which credentials did it use? Was it acting as the user, an automation, a service account, or another agent? Was the action approved before it ran? Can security replay it? Can compliance prove what the agent knew, what it proposed, what the runtime allowed, and what actually happened?

That is the gap Tandem is built to close.

Tandem is a source-available, open-core governed runtime for AI-first work. It is not another chat wrapper, and it is not just an agent framework. It is the authority layer underneath agents as they move from answering questions to acting on company systems. The repo says it plainly: Tandem is a governed runtime that controls what agents can see, which tools they can discover, which actions they can execute, when humans must approve, and what evidence survives. See the Tandem README.

The model is not the access-control perimeter. The runtime is.

---

The old AI stack was built for suggestions. The new stack is doing work.

Most early AI governance grew up around model inputs and outputs. Did the prompt contain sensitive data? Did the model produce unsafe language, hallucinate, or leak something confidential? Those questions still matter, but they are not enough for agents.

An agent can use tools, call APIs, read files, and mutate records. It can create tickets, send messages, run code, trigger workflows, and delegate to other agents. Once an AI system can act, the problem shifts from content moderation to runtime authority.

The U.K. National Cyber Security Centre makes the core point clearly: current large language models do not enforce a reliable boundary between data and instructions inside a prompt. Under the hood there is no durable separation between what the application meant as instruction and what arrived as untrusted content. NCSC argues that secure AI systems need deterministic safeguards that constrain what the system can do, especially when the model can call tools or APIs. See NCSC, "Prompt injection is not SQL injection".

That should matter to every developer and every CISO. A confused model with no tools is a quality problem. A confused model with production tools is an authority problem.

---

MCP solved connection. It did not solve authority.

The Model Context Protocol is one of the most important shifts in AI infrastructure. MCP gives AI applications a standard way to connect to external systems, tools, data sources, and workflows. The official docs describe it as an open-source standard for connecting AI applications to external systems, including local files, databases, search engines, and specialized workflows. See the MCP introduction. Anthropic's original announcement framed the problem as integration fragmentation: every new data source required custom work, and MCP aimed to replace that with a single open protocol. See Anthropic's MCP announcement.

That is a major step forward. But connection is not authority.

A protocol can define how an AI client talks to a tool server. It does not decide whether this user, in this tenant, inside this workflow, at this step, with this credential, should be allowed to call this tool with these arguments. MCP's own security guidance points the same way. The authorization spec requires resource indicators and token audience validation so tokens are issued for, and accepted by, the intended MCP server. See the MCP authorization specification. The security best-practices guide warns against scope inflation and recommends progressive, least-privilege scopes, targeted elevation, precise scope challenges, and logging elevation events with correlation IDs. See MCP security best practices.

The security community is converging on the same concern. OWASP's MCP Top 10 includes token mismanagement, privilege escalation through scope creep, tool poisoning, command injection, insufficient authentication and authorization, lack of audit and telemetry, shadow MCP servers, and context over-sharing. See OWASP MCP Top 10.

MCP makes agents more useful by making tools easier to reach. That is exactly why runtime governance becomes non-optional.

---

Guardrails help. They are not the runtime.

Prompt guardrails, model policies, API gateways, output filters, and human review are all useful, and you should use them. But none of them, by themselves, creates an authoritative execution environment.

The central question is not "did we tell the model what it should do?" It is "can the system prevent the action unless authority is proven?" That is the line between advisory safety and runtime enforcement.

A system prompt can tell the model not to use a dangerous tool; a runtime can make sure the model never sees that tool unless policy allows it. A policy prompt can ask the agent to wait for approval; a runtime can pause the run, create a durable approval request, capture the proposed action, record who approved it, and resume only the approved path. A connector wrapper can hide a credential; a runtime can broker credential references, validate tenant scope, prevent raw secret exposure, and emit audit evidence. A log can tell you what happened after the fact; a runtime receipt can prove why the action was allowed before it happened.

That is the layer Tandem is building.

---

This is already happening in production

The clearest external validation for runtime authority is not theoretical. It is showing up inside the most AI-native engineering organizations on earth.

In a public conversation, Emma Tang, who leads data platform infrastructure engineering at OpenAI, described what happens when autonomous coding agents start operating across real company systems. Her team sits at the platform layer: the data systems, streaming systems, event buses, ML infrastructure, internal data movement, training-data preparation, eval-data preparation, and other low-level systems that product and research teams depend on.

That platform layer is already using agents in serious operational workflows. Tang described an internal release process that used to require people to manually watch jobs, validate stages, check results, and promote releases through staging, canaries, and production. Now, she said, the release process is controlled by an agent: it watches status, posts updates to Slack, triages failures, and suggests what may be wrong.

She also described an export workflow where a user launched a data export job and went to sleep. The agent found issues, inspected multiple internal systems, pinged the support channel, discovered a small bug several layers deep, patched or worked around it, and completed the job before the user woke up.

That is the upside.

The risk appears when this same acceleration hits infrastructure teams unevenly. Tang described upper-layer teams moving at AI speed while platform teams still carry the human responsibility for keeping systems reliable. Users may generate workloads they do not fully understand, then platform teams inherit the burden of running, debugging, and securing that code.

The most important part of the talk was not that agents are bad. It was that they are useful, goal-directed, and increasingly capable, which means they also find paths you did not expect. Tang described agents discovering internal APIs that "should have never been exposed," doing "squirrely stuff" even when best practices were encoded in skills or agent markdown files, and generating PRs that felt "almost quite adversarial" because they changed internal APIs to accomplish a narrow goal in ways that could break other teams.

She also described the infrastructure side of the problem: platform agents need access to many more live operational primitives than a frontend coding agent. To diagnose something like a Spark cluster, an agent may need logs, observability, Kubernetes, pods, shuffle services, routing services, quota management, and many other live systems. In that environment, you cannot simply let the agent try things to see what works. The blast radius is too large.

That is exactly the gap Tandem is built for. A better model is not enough. A longer prompt is not enough. Skills and agent markdown files help, but they are still model-mediated guidance. The production problem is authority: which tools the agent can discover, which systems it can touch, which credentials it can use, which actions require approval, which memory it can retrieve, which artifacts prove the work, and which audit trail survives after the run.

The more capable agents become, the more important the runtime becomes.

---

What we mean by an authoritative runtime

An authoritative runtime is the system of record for agent execution. It sits between model intent and real-world side effects, and it does not merely observe work after the fact. It decides what can be seen, retrieved, called, approved, executed, remembered, exported, and audited.

In Tandem, the model can propose. The runtime decides.

At minimum, an authoritative runtime answers seven questions on every meaningful action:

1. Who or what created this action? A human user, an automation, a service account, a delegated agent, or an agent spawned by another agent?

2. What is the agent trying to do? Is the action a read, write, send, execute, export, approve, delegate, or admin operation?

3. What authority is being used? Which tenant, principal, resource scope, grant, credential reference, and data boundary apply?

4. Which tools should the model even see? The safest tool call is the one the model cannot discover unless the runtime projects it into scope.

5. Which actions require approval? Approval should attach to a concrete action envelope, not a vague "continue" button.

6. What state did the agent rely on? Long-running work needs durable sessions, runs, messages, memory, artifacts, checkpoints, and replayable events.

7. Can the enterprise prove what happened? Audit evidence has to survive outside the model context window.

That is what separates an agent demo from production AI work.

---

Tandem's runtime model

Tandem puts authority, state, tools, memory, approvals, artifacts, and evidence in the engine. The product surfaces (desktop, TUI, web control panel, SDKs, and channels) are entrypoints, not separate runtimes. The repo's runtime infrastructure doc states this directly: chat, desktop, web, channels, and SDKs submit, observe, and approve work through the same engine-owned model, while the runtime remains the source of truth. See Tandem AI Runtime Infrastructure.

flowchart TD
    User["User / Developer / Operator"]
    SDK["SDKs"]
    Panel["Web Control Panel"]
    Desktop["Desktop / TUI"]
    Channels["Slack / Discord / Telegram"]

    Engine["Tandem Engine Runtime"]
    Intent["Intent"]
    Projection["Authority Projection"]
    Plan["Plan Preview / Apply"]
    Execution["Scoped Execution"]
    Tools["Built-in Tools + MCP Connectors"]
    Memory["Permissioned Memory"]
    Approvals["Approval Gates"]
    Artifacts["Artifacts + Validation"]
    Audit["Receipts + Audit Trail"]
    Enterprise["Enterprise Sidecar / Policy Bridge<br/>(roadmap/private layer)"]

    User --> SDK
    User --> Panel
    User --> Desktop
    User --> Channels

    SDK --> Engine
    Panel --> Engine
    Desktop --> Engine
    Channels --> Engine

    Engine --> Intent
    Intent --> Projection
    Projection --> Plan
    Plan --> Execution
    Execution --> Tools
    Execution --> Memory
    Execution --> Approvals
    Execution --> Artifacts
    Execution --> Audit

    Enterprise -. identity / tenant / policy / audit .-> Engine

The boundary is simple:

No agent action should reach a tool, credential, memory space, connector, workflow, or external system unless the runtime can prove that the action is authorized for this actor, in this context, at this moment.

---

What this looks like under the hood

Tandem's current main branch already contains the runtime primitives behind this thesis.

1. Tenant-aware runtime state

Tandem sessions carry tenant context, and can carry verified tenant context. Local usage defaults to a local implicit tenant, while hosted and enterprise paths thread explicit tenant identity through runtime state. See crates/tandem-types/src/session.rs.

This matters because enterprise AI work is not flat. A company memory may know a great deal, but an agent acting for one team, workspace, user, tenant, project, or automation should only retrieve the slice it is allowed to use.

2. Strict authority projection

The enterprise contract defines the vocabulary of authority: TenantContext, VerifiedTenantContext, StrictTenantContext, AuthorityChain, PrincipalRef, ResourceRef, ResourceScope, ScopedGrant, DataBoundary, AccessPermission, and DataClass. See crates/tandem-enterprise-contract/src/lib.rs and crates/tandem-types/src/lib.rs.

That gives Tandem a concrete way to represent who is acting, over which resource, with which permissions, under which data boundary, and with which proof of context. The strict evaluation path can deny expired context, denied data classes, explicitly denied resources, matching deny grants, resources outside projected scope, or missing allow grants. See StrictTenantContext::evaluate_access.

This is the difference between "the prompt said the user has access" and "the runtime evaluated a scoped grant."

3. Scoped tools before model invocation

Tandem's tool capability layer classifies tool surfaces and derives conservative security descriptors for built-in, provider, and MCP tools. It marks tools by required permissions, resource kinds, data classes, admin surfaces, credential access, external side effects, and default visibility, then decides whether a given tool schema should be visible under a strict tenant context. See crates/tandem-core/src/tool_capabilities.rs.

That is a deliberate design choice. The model should not receive a catalog of every tool that exists. It should receive the tools the runtime projects into scope.

sequenceDiagram
    participant M as Model
    participant R as Tandem Runtime
    participant A as Authority Context
    participant T as Tool Registry
    participant P as Approval Gate
    participant X as External System
    participant L as Audit / Receipts

    M->>R: Propose tool call
    R->>A: Evaluate tenant, principal, grants, data boundary
    A-->>R: Allow / deny / not applicable
    R->>T: Check tool security descriptor
    T-->>R: Required permission, resource kind, data class, side effect
    alt approval required
        R->>P: Create approval request
        P-->>R: Approve / rework / cancel
    end
    alt authorized
        R->>X: Execute scoped action
        X-->>R: Result
        R->>L: Write receipt and audit event
        R-->>M: Return result
    else denied
        R->>L: Record denial
        R-->>M: Return blocked reason
    end

4. Step-level tool and MCP policy

Automation V2 supports agent profiles with tool allowlists, MCP server policy, MCP tool policy, approval policy, per-node tool and MCP policy, maximum tool calls, output contracts, prewrite gates, required evidence, required tool calls, validation profiles, repair budgets, and execution limits for runtime, tokens, tool calls, and cost. See crates/tandem-server/src/automation_v2/types.rs.

That means Tandem narrows execution at the step level. The research step does not need the same tools as the write step. The draft step does not need the same authority as the send step. The approval step should not inherit every capability from the investigation step.

5. Permissioned memory

Tandem's memory layer is tenant-scoped and supports enterprise access filtering. Memory chunks carry source-binding metadata, resource references, and data classes, and the access filter evaluates whether strict tenant context grants Read on the bound resource and data class before a source-bound chunk can participate. See crates/tandem-memory/src/types.rs.

The tests are the point here. Current coverage proves that source-bound chunks stay hidden without a strict projection, that a grant for a different resource does not reveal the chunk, that a matching resource and data-class grant does reveal it, and that tenant A cannot retrieve tenant B's source-bound chunks even when binding IDs, native paths, and query phrases overlap. See crates/tandem-memory/src/manager_parts/part02.rs.

That is exactly the boundary enterprise buyers ask for. Not company memory. Permissioned company memory.

6. Connector and source-binding governance

Tandem's enterprise contract now includes connector instances, connector lifecycle states, credential references, source bindings, ingestion policies, source objects, ingestion jobs, ingestion quarantine, and scoped memory chunk references. Credential references point to secrets rather than raw credential values, and the contract validates secret references against tenant context. See crates/tandem-enterprise-contract/src/lib.rs.

This is the foundation for governed ingestion. A connector is not just "connected." It has tenant context, lifecycle state, credential class, source-bound resources, data classification, ingestion policy, quarantine behavior, and audit implications.

7. Runtime approval gates

Tandem approvals are normalized into a common request shape across surfaces. A pending approval can include source subsystem, tenant reference, run ID, node ID, workflow name, action kind, action preview markdown, allowed decisions, rework targets, instructions, decision actor, decision time, and feedback. See crates/tandem-types/src/approvals.rs.

That matters because human approval is usually implemented as a vague chat message. In Tandem, approval is runtime state. The approver is not approving "the agent." They are approving a bounded action in a specific run, under a specific tenant, with a specific preview and a durable decision record.

8. Governance for recursive agents

The governance contract includes automation provenance, creator and root actor references, ancestor chains, declared capabilities, creation limits, lineage depth limits, quota overrides, capability approvals, lifecycle review, health findings, spend windows, weekly spend caps, pause behavior, dependency revocation, retirement, and a policy engine trait for authorization decisions. See crates/tandem-enterprise-contract/src/governance.rs.

This is where the enterprise story gets sharper. The risk is not only that an agent used a tool. The real risk is that an agent created another agent, granted it capabilities, ran it repeatedly, spent money, drifted from its original purpose, and nobody had a runtime record of lineage or review. Recursive AI work needs runtime governance.

---

Why manually building this per use case is expensive

Many enterprises will try to build an authority layer themselves. At first that feels rational. Each use case seems unique, with its own systems, data, teams, risk levels, and approval paths.

Then the hidden cost appears. The support agent needs approvals before refunds. The finance agent needs scoped access to ERP data. The security agent needs evidence-grade audit logs. The engineering agent needs repo permissions, shell constraints, and PR receipts. The compliance agent needs immutable records and human sign-off. The sales ops agent needs CRM writes but not bulk export. The incident agent needs temporary elevation, then automatic expiry.

Every team ends up rebuilding the same primitives: identity, tenant context, tool registry, tool scoping, MCP connector policy, credential brokering, approval queues, memory permissions, audit logs, artifact validation, replay, spend limits, lifecycle reviews, and incident response. That duplication is not just slow. It is dangerous.

flowchart LR
    subgraph Manual["Manual per-use-case governance"]
        A1["Support agent<br/>custom approvals"]
        A2["Finance agent<br/>custom credential scoping"]
        A3["Security agent<br/>custom audit logs"]
        A4["Engineering agent<br/>custom shell/repo policy"]
        A5["Compliance agent<br/>custom evidence exports"]
    end

    subgraph Problems["What accumulates"]
        P1["Inconsistent policy semantics"]
        P2["Credential sprawl"]
        P3["Approval fatigue"]
        P4["Fragmented audit trails"]
        P5["Security review bottlenecks"]
        P6["Hard incident response"]
    end

    subgraph Tandem["Tandem governed runtime"]
        R1["Tenant context"]
        R2["Scoped grants"]
        R3["Tool/MCP projection"]
        R4["Credential references"]
        R5["Approval gates"]
        R6["Artifacts + validation"]
        R7["Receipts + audit"]
    end

    A1 --> Problems
    A2 --> Problems
    A3 --> Problems
    A4 --> Problems
    A5 --> Problems

    Problems --> Tandem

The build-versus-adopt question is not "can we wire up an agent?" Of course you can. The real question is how many times you want to rebuild authority. Tandem turns these controls into reusable runtime primitives.

---

What has changed for enterprise buyers

The enterprise story is sharper now than a generic "governed AI" pitch. Tandem's current direction has four concrete lanes.

Lane 1: tenant and authority projection. The runtime foundation now includes tenant context, verified tenant assertions, strict projections, principals, authority chains, scoped resources, grants, and data boundaries. This creates a vocabulary for enterprise authorization that travels through sessions, memory, tools, connectors, automations, and audit surfaces.

Lane 2: source-bound memory and connector governance. Enterprise memory is moving from "retrieve useful context" to "retrieve context only when the runtime can prove the caller has read authority over the source-bound resource and data class." That distinction is critical for regulated teams. A compliance agent may need one policy collection. A finance agent may need a different source binding. A support agent may need customer-facing knowledge but not payroll, executive, or regulated source objects.

Lane 3: tool visibility and side-effect control. Tandem classifies tool surfaces, hides risky tools by default, and filters provider-visible tool schemas when strict tenant context is present. Governance happens before the model call, not only after the model proposes a risky action. That matters most in MCP ecosystems, where tool catalogs become large, dynamic, and hard to reason about by hand.

Lane 4: enterprise administration and proof path. The unreleased 0.5.10 changelog shows a major enterprise push: connector source-binding contracts, organization-unit registries, source-bound memory retrieval guards, response-cache partitioning, MCP discovery authorization filtering, provider tool-schema authorization filtering, connector lifecycle management, credential references, ingestion quarantine, Google Drive guardrails, org-unit memberships and grants, and artifact export filtering. See the Tandem changelog.

The message is not that Tandem has every enterprise feature finished. It is better than that:

Tandem already has the runtime foundation enterprise AI work needs, and the enterprise layer is being built around that foundation instead of bolted on after the fact.

---

What we are not claiming yet

Enterprise buyers appreciate ambition. CISOs appreciate precision. So we should be explicit.

Tandem is not yet a complete enterprise platform with full RBAC, OIDC, SCIM, SIEM export, SOC2, and private sidecar enforcement. The enterprise readiness doc says the current proof is the runtime foundation those features attach to, while full enterprise identity, RBAC and policy enforcement, OIDC, SCIM, SIEM export, SOC2, and private sidecar enforcement remain in progress or planned. See Tandem Enterprise Readiness.

Approval gates are also not, by themselves, a complete authorization boundary. For regulated or customer-impacting actions, the runtime should verify tenant, policy, approval, proposed-action identity, and capability evidence at the protected tool call. Tandem's enterprise readiness doc makes that boundary explicit.

That honesty makes the story stronger. The enterprise AI market does not need another vendor pretending a button is governance. It needs infrastructure that treats governance as runtime state.

---

Why source-available matters

Authority layers should not be magic. If a runtime decides what agents can see, remember, approve, and execute, developers need to understand it, security teams need to test it, regulated customers need to inspect it, and platform teams need to operate it where their data, connectors, credentials, and audit evidence live.

That is why Tandem is open-core and source-available. The repo license map is intentionally explicit: most SDK, runtime, client, local execution, and support components use permissive open-source licenses, while selected governance and plan-compilation components are source-available under BUSL-1.1. See Tandem Licensing.

That is not just a licensing posture. It is a trust posture. The core runtime surface should be inspectable and the governance layer reviewable. Enterprise customers should not have to trust a black box sitting between AI systems and company action.

---

Tandem is not another agent framework

The world does not need another place to define an agent loop. Developers already have excellent tools for prompting, orchestration, model access, workflow graphs, evals, tool calling, and MCP servers.

Tandem is designed to sit underneath and beside those tools as the runtime authority layer for AI-first work. Use the model you trust. Use the framework you like. Use MCP where it helps. Use your existing identity provider, ticketing system, cloud, and data stack. But when an agent wants to act, route that action through a runtime that owns authority, state, approvals, artifacts, and evidence.

That is the Tandem bet.

---

The future of AI-first work needs runtime authority

The first wave of enterprise AI was about answers. The next wave is about work, and that work will be long-running, delegated, tool-using, stateful, collaborative, and increasingly autonomous. It will cross systems, users, credentials, teams, data boundaries, and compliance obligations.

The organizations that win will not simply give agents more tools. They will give agents the right authority, at the right time, with the right proof.

That is what Tandem is building. Not another chatbot, not another orchestration wrapper, not another policy prompt, but a governed runtime for AI-first work: a place where developers can build freely, CISOs can inspect enforcement, platform teams can avoid rebuilding authority per use case, and enterprises can prove what happened.

Because in production, trust is not what the model says. Trust is what the runtime can enforce.

---

Source pack

Core Tandem sources:

• Tandem README
• Tandem AI Runtime Infrastructure
• Tandem Enterprise Readiness
• Tandem Enterprise Proof Walkthrough
• Tandem Licensing
• crates/tandem-enterprise-contract/src/lib.rs
• crates/tandem-enterprise-contract/src/governance.rs
• crates/tandem-core/src/tool_capabilities.rs
• crates/tandem-server/src/automation_v2/types.rs
• crates/tandem-memory/src/types.rs
• crates/tandem-memory/src/manager_parts/part02.rs
• crates/tandem-types/src/approvals.rs
• Tandem changelog

External sources:

• NCSC: Prompt injection is not SQL injection
• Model Context Protocol introduction
• Anthropic: Introducing the Model Context Protocol
• MCP authorization specification
• MCP security best practices
• OWASP MCP Top 10