Every Enterprise Will Have Its Own AI Harness

I think every large enterprise is going to have its own AI harness.

Not necessarily a proprietary harness built from scratch. More likely, it will be an open core that the enterprise configures with its own identity systems, model gateways, internal tools, data sources, policies, approval processes, and audit requirements.

That harness could become the shared runtime behind a large part of the company’s internal AI work.

This matters because the current pattern does not scale well. A team wants an internal assistant, so it builds an application. Another team wants a policy search tool, so it builds a second application. Security wants a review tool. Support wants a ticket assistant. Engineering wants a code and Jira assistant. Each project ends up rebuilding some version of model access, authentication, connectors, permissions, logging, and policy checks.

After enough projects, the company has dozens or hundreds of small AI applications with overlapping infrastructure and different security assumptions.

I believe the enterprise harness is how we get out of that cycle.

What I mean by an enterprise harness

I do not mean one giant chat window that replaces every internal application.

Teams will still build applications, workflows, command-line tools, and specialized interfaces. The difference is that those products can become thinner. Instead of every application building its own integration and governance layer, it can use a shared enterprise harness.

The harness becomes the place where the company standardizes the hard parts:

• Employee and workload identity
• Access to approved models
• Model routing through the company gateway
• Internal system connectors
• Secrets and credential resolution
• Data classification and egress checks
• Human approvals
• Cybersecurity and risk reviews
• Audit and observability
• Usage limits, cost controls, and regional rules

The applications sit above that shared layer.

Internal apps, developer tools, agents, and experiments
                         ↓
                Enterprise AI harness
  ┌─────────────────────────────────────────────────┐
  │ Identity  Model gateway  Connectors  Approvals │
  │ Policy    Security checks  Audit     Cost rules │
  └─────────────────────────────────────────────────┘
                         ↓
   Jira  Confluence  GitHub  ServiceNow  Slack  Data

This is the same reason enterprises standardize cloud platforms, identity providers, API gateways, and CI systems. A shared foundation reduces repeated work and gives security teams a consistent control point.

Plugins turn the harness into the company’s harness

The plugin model is what makes this idea practical.

A generic open-source harness cannot know an enterprise’s internal project structure, risk model, cybersecurity policies, model providers, or approval process. It should not try to know them.

Instead, the enterprise adds plugins and providers for the capabilities it needs.

For example:

• A Confluence plugin can search internal documentation with permission checks.
• A Jira plugin can read, propose, create, or review issues.
• A model-gateway plugin can route requests through the approved provider and enforce model restrictions.
• A policy-knowledge plugin can retrieve the current security, privacy, and generative AI policies with source and version information.
• A cybersecurity review plugin can check a proposed design against internal controls.
• A risk and compliance plugin can collect evidence and flag missing reviews.
• A DLP plugin can stop secrets or restricted data from leaving an approved boundary.
• An approval plugin can bind a human decision to one exact action.
• An audit plugin can record the final outcome in the company’s SIEM.

This is more useful than building a separate application for every combination of these capabilities.

Once the capability exists as a governed plugin, many internal applications can use it. A developer portal, a support workflow, a security review assistant, and a command-line tool might all use the same Jira connector and the same policy checks.

The policy distinction matters

There is an important technical distinction here.

A plugin that reads company policy can help an employee understand the policy. It can answer questions, cite the source, show the effective date, and explain which review is required.

That is not the same as enforcing the policy.

Enforcement should be deterministic and external to the model. If the policy says only projects ENG and SEC are allowed, the harness should deny any other project through code or a policy-decision service. The model should not be asked to interpret its way around the rule.

In other words, an enterprise harness needs both:

1. Policy knowledge, so applications can find and explain the company’s rules.
2. Policy enforcement, so protected actions are allowed, denied, or sent for approval in a predictable way.

This separation is one of the most important parts of the architecture. It gives employees useful context while keeping authorization outside the conversation.

What happens to the hundreds of internal AI apps?

They do not all disappear, and they should not.

A sales application and a cybersecurity review tool have different users, workflows, interfaces, and measures of success. They may still need separate products.

What can disappear is a large amount of duplicated backend work.

Each application should not need to invent its own way to:

• Authenticate an employee
• Reach Confluence or Jira
• Select an approved model
• Prevent restricted data from leaving the company
• Request approval for a write
• Record an audit trail
• Apply retention and regional rules
• Handle vendor failures and rate limits

With a shared harness, an application can focus on the job it was built to do.

This also changes experimentation. A team can test a new use case against mock connectors and audit-only policy. If the idea proves useful, it can move toward controlled access, approval-gated writes, and production monitoring without replacing the entire foundation.

The path from experiment to production becomes a profile and control change, not a full rewrite.

A practical example

Imagine an engineer asks an internal tool to review a proposed service and open any required work items.

The application could use one shared harness to:

1. Read the architecture document from Confluence.
2. Retrieve the current cybersecurity and data-handling policies.
3. Run a structured security review plugin.
4. Check the service against the company’s risk rules.
5. Propose Jira issues for missing controls.
6. Ask a person to approve the exact issues.
7. Create the approved issues with least-privilege credentials.
8. Verify that Jira accepted the changes.
9. Send the final outcome to the enterprise audit system.

The user sees one coherent workflow. Underneath it, each capability has a narrow contract and a clear owner.

Security can maintain the policy and review plugins. The platform team can maintain identity, model routing, and audit. Application teams can compose those capabilities without copying them.

That is the part I find most interesting. The harness is not only a tool runner. It becomes a way to encode how the enterprise wants AI-enabled work to happen.

Why the DeepSeek Harness release is an important milestone

DeepSeek recently open-sourced its Harness. I cloned it, studied the Cordis plugin architecture, installed it locally, and built an enterprise suite on top of it.

The technical milestone is not simply that another coding agent is available. The important part is that the harness itself is open and composable.

An enterprise can inspect the runtime, build its own plugins, create different profiles, replace providers, and keep internal controls outside a vendor-managed black box. That makes it possible to test this enterprise-harness model with real code today.

I released my implementation as the DeepSeek Harness Enterprise Suite.

The first release composes three plugin roles:

DeepSeek Harness profile
  ├─ enterprise-atlassian
  ├─ enterprise-policy
  └─ enterprise-audit

A protected tool request follows this path:

Tool request
  → validate arguments
  → evaluate policy
  → apply project, space, and DLP guards
  → request approval when required
  → resolve credentials
  → call the enterprise API
  → validate the structured result
  → verify the outcome
  → record the final redacted audit event

Connectors do not decide enterprise authorization. Policy plugins do not hold vendor credentials. Audit observes the final outcome rather than the agent’s original intention.

That separation lets an enterprise replace any layer without rewriting every tool.

What the open-source suite includes

Version 0.1.0 currently provides:

• Confluence search
• Jira read, create, and deterministic issue review
• Jira project and Confluence space allowlists
• Configurable DLP checks
• Approval-gated Jira writes
• Credential references instead of credential values in configuration
• Redacted JSONL audit records
• Shared connector utilities
• Connector and policy plugin templates
• A plugin project generator
• A machine-readable roadmap of 39 enterprise capabilities
• Tests, CI, release packaging, checksums, a threat model, and deployment guidance

The suite starts in mock mode. Installing it cannot modify a real Atlassian tenant until an operator explicitly enables live mode and configures credential references.

From a DeepSeek Harness source checkout:

export DSH_HOME=/absolute/path/to/an/evaluation-home
pnpm dsh plugin --profile web add github:mickymultani/deepseek-harness-enterprise-suite#v0.1.0
pnpm dsh --profile web --dump-config
pnpm dsh web --no-open

To scaffold a new connector project:

npx dsh-enterprise-suite create-dsh-enterprise-plugin knowledge-search

The roadmap is an enterprise capability map

The roadmap covers more than application connectors.

It includes identity propagation, Vault and cloud secret providers, OPA and Cedar policy decisions, model gateways, OpenTelemetry, SIEM export, enterprise search, ServiceNow, GitHub Enterprise, security operations, cloud controls, legal, privacy, vendor risk, finance, HR, and customer support.

The order matters:

1. Establish identity, secrets, policy, and audit.
2. Add permission-aware, read-only knowledge.
3. Add proposed actions and review workflows.
4. Add approval-gated writes with verification.
5. Add multi-tenant scale, regional isolation, and operational guarantees.

A connector that can call an API is not automatically ready for enterprise production. It also needs ownership, authorization, data handling, failure behavior, testing, audit, and incident procedures.

What enterprises gain

If this pattern works, enterprises gain more than technical reuse.

They gain a standard place to answer important questions:

• Which models are employees allowed to use?
• Which data can go to which model?
• Which tools can read and which can write?
• Which actions require approval?
• Which internal policy version was applied?
• Which employee, workload, and application made the request?
• What happened in the external system?
• Can the company reproduce the decision later?

That gives platform, security, risk, and application teams a common surface.

It also gives leadership a clearer view of experimentation. Instead of discovering untracked applications after they are already in use, the company can provide a supported path for teams to build and test ideas with approved models, connectors, and controls.

My view

I think open, plugin-based harnesses will become a standard part of the enterprise technology stack.

Companies will not all use the same plugins or policies. That is the point. Each enterprise will shape the harness around its own systems, risk tolerance, regulatory obligations, and ways of working.

The shared core provides the runtime. The internal plugins make it the company’s runtime.

That is why I see the open-sourcing of DeepSeek Harness as a meaningful milestone for enterprise AI. It creates a practical foundation for moving from scattered experiments and duplicated internal applications toward a governed, reusable platform.

The project is open source under the MIT license:

github.com/mickymultani/deepseek-harness-enterprise-suite

I would like to hear how other platform, security, and engineering teams see this. Will enterprises converge on one internal harness? Which capabilities need to be standardized first? And where should the boundary sit between the shared harness and the applications built on top of it?