# OpenWork Enterprise Security and Outbound Access Requirements: Complete Guide

> Learn OpenWork Enterprise security and outbound access requirements. Understand repository security policies and outbound allowlist controls for robust network security.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: how-to-guide
- Published: 2026-08-01

---

**OpenWork Enterprise enforces security through a repository-wide security policy and strictly controls outbound network access via a machine-readable allowlist.**

Enterprise deployments of the [different-ai/openwork](https://github.com/different-ai/openwork) repository must satisfy two complementary requirement sets: a comprehensive **security policy** that governs secret handling and vulnerability management, and an **outbound-network allowlist** that restricts external connections to pre-approved hosts only. This guide breaks down both requirement categories with specific implementation details from the source code.

---

## Security Policy Requirements

Every OpenWork Enterprise deployment must comply with the repository-wide security policy defined in [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md). This policy establishes three mandatory practices that harden the codebase against common attack vectors.

### No Secrets in Source Code or Logs

The policy strictly prohibits exposure of **secrets, API keys, or credentials** in any source code, configuration files, or log output. This applies to:

- Hardcoded tokens in TypeScript/JavaScript files
- Environment variable dumps in error handlers
- Debug logging that might capture sensitive headers

### CI-Based Security Checks

All pull requests and releases must pass automated security validations. The CI pipeline runs:

- **Secret-scanning** to detect accidentally committed credentials
- **Dependency-vulnerability audits** to flag known CVEs in npm packages
- **Enterprise-readiness gate** validation through mock-server tests

### Enterprise-Ready MCP Tool Validation

The most distinctive security requirement is the **"Enterprise-ready" readiness gate**. This gate validates that every published **MCP (Model Context Protocol) tool set** meets enterprise criteria defined in the mock-server test suite.

In [`packages/enterprise-mcp-mock-server/test/probe-boundaries.test.ts`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-mock-server/test/probe-boundaries.test.ts), the test suite enforces this gate:

```typescript
// packages/enterprise-mcp-mock-server/test/probe-boundaries.test.ts
test("bounded tool schemas support nested enterprise payloads and reject hostile schema keys", () => {
  // …test logic…
  // If the tool catalog is empty, the probe fails with an enterprise‑readiness error
  if (toolNames.size === 0) {
    throw new ProbeFailure("MCP_TOOL_DISCOVERY", "catalog_empty", "Enterprise readiness not satisfied");
  }
});

```

Tools that fail this probe cannot be published for enterprise use, ensuring only hardened, bounded tool schemas reach production environments.

---

## Outbound Network Access Requirements

OpenWork Enterprise operates under a **default-deny network posture**. Instances may only initiate outbound connections to hosts explicitly listed in the machine-readable allowlist.

### The Allowlist Structure

The canonical source of truth is [`docs/enterprise/outbound-access.json`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.json), a JSON file containing an array of permitted host patterns. The human-readable companion [`docs/enterprise/outbound-access.md`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.md) documents the policy rationale and update procedures.

Example structure of the allowlist:

```json
{
  "hosts": [
    "api.openai.com",
    "*.anthropic.com",
    "registry.npmjs.org"
  ],
  "version": "2024.06.01",
  "last_reviewed": "2024-06-01T00:00:00Z"
}

```

### CI Enforcement via check-outbound-access.mjs

The script `scripts/check-outbound-access.mjs` parses the allowlist and validates that no code attempts connections to unapproved hosts. This script runs in CI and fails the build on violations:

```javascript
// scripts/check-outbound-access.mjs (excerpt)
import fs from "fs";
import path from "path";

const manifestPath = path.join(repoRoot, "docs/enterprise/outbound-access.json");
const json = JSON.parse(fs.readFileSync(manifestPath, "utf‑8"));
if (!Array.isArray(json.hosts)) {
  throw new Error("docs/enterprise/outbound-access.json must contain a hosts array");
}

```

The script typically integrates with:

- **Static analysis** of HTTP client calls (fetch, axios, node-fetch)
- **Runtime network interception** in test environments
- **Container egress policies** for deployed applications

### Violation Consequences

Any attempt to contact a host not present in [`outbound-access.json`](https://github.com/different-ai/openwork/blob/main/outbound-access.json) causes:

- Immediate **CI check failure**
- **Blocked merge** of the offending pull request
- **Audit log entry** for security review

---

## Key Implementation Files

| File | Purpose |
|------|---------|
| [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md) | Repository-wide security policy: secrets handling, vulnerability checks, enterprise-readiness criteria |
| [`docs/enterprise/outbound-access.md`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.md) | Human-readable outbound access policy documentation |
| [`docs/enterprise/outbound-access.json`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.json) | Machine-readable allowlist of permitted external hosts |
| `scripts/check-outbound-access.mjs` | CI validation script that enforces the outbound allowlist |
| [`packages/enterprise-mcp-mock-server/test/probe-boundaries.test.ts`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-mock-server/test/probe-boundaries.test.ts) | Test suite implementing the enterprise-ready MCP tool gate |

---

## Deployment Checklist

Use this checklist when preparing an OpenWork Enterprise deployment:

1. Verify [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md) compliance across all custom code
2. Confirm no secrets in environment variables beyond secure secret management
3. Review [`docs/enterprise/outbound-access.json`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.json) against your infrastructure needs
4. Submit pull request to add any required hosts to the allowlist with business justification
5. Ensure CI passes `check-outbound-access.mjs` and [`probe-boundaries.test.ts`](https://github.com/different-ai/openwork/blob/main/probe-boundaries.test.ts)
6. Document any exceptions with security team approval

---

## Summary

- **Security policy** in [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md) mandates secret-free code, CI security checks, and enterprise-ready MCP tool validation
- **Outbound access** is restricted to hosts listed in [`docs/enterprise/outbound-access.json`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.json), enforced by `scripts/check-outbound-access.mjs`
- **Enterprise readiness gate** in the mock-server test suite ensures only bounded, secure MCP tools reach production
- Both requirements operate as **default-deny policies**: violations block deployment

---

## Frequently Asked Questions

### What happens if my code needs to connect to a host not in the allowlist?

Submit a pull request modifying [`docs/enterprise/outbound-access.json`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.json) to add the required host. Include business justification and security review approval. The change takes effect after CI passes and maintainers merge. Until then, `scripts/check-outbound-access.mjs` will fail your build.

### How does the enterprise-readiness gate differ from standard security scanning?

Standard security scanning detects known vulnerabilities and secrets. The **enterprise-readiness gate** specifically validates MCP tool schemas—ensuring they support nested enterprise payloads, reject hostile keys, and maintain bounded operation scopes. This is implemented in [`packages/enterprise-mcp-mock-server/test/probe-boundaries.test.ts`](https://github.com/different-ai/openwork/blob/main/packages/enterprise-mcp-mock-server/test/probe-boundaries.test.ts) as custom test logic, not generic tooling.

### Can we disable outbound access restrictions for development environments?

No. The `check-outbound-access.mjs` script runs in all CI contexts. For local development, you can modify [`docs/enterprise/outbound-access.json`](https://github.com/different-ai/openwork/blob/main/docs/enterprise/outbound-access.json) temporarily, but such changes cannot be merged without security review. The policy intentionally prevents environment-based variance that could mask production issues.

### Where are security incidents reported for OpenWork Enterprise?

Follow the disclosure process in [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md). The policy defines contact methods for reporting vulnerabilities and the timeline for maintainer response. Enterprise deployments should also monitor the repository for security advisories and update promptly when patches release.