WorkFoundry helps AI agents and technical teams check connections, control data flow, and operate complex workflows with clearer boundaries and better evidence.
Our first hosted pilot, Ingress Shield, checks proposed agent, API, and webhook connections before action, while providing bounded controls for declared sandbox traffic.
An agent describes the intended connection.
{
"source": "customer.created/v1",
"target": "payment.cleared/v1",
"mode": "preflight"
}
The declared producer cannot satisfy the required consumer event.
Correct the declared connection, then submit a new draft for review.
Foundation // Atom Flux
ATOM FLUXThe operating substrate beneath WorkFoundry products.A local-first foundation for explicit components, governed workflow plans and evidence-led operation.
Agent Preflight for read-only connection checks; Webhook Boundary for declared traffic.
Product 02 // direction
Inspectable data quality, machine-learning comparison and evidence.
Resources // practical guidanceGuidesGuides to Agent Preflight, Webhook Boundary and sandbox delivery.
Agent Preflight uses the Model Context Protocol (MCP), a standard way for an AI assistant to request tools. It lets approved coding and agent clients inspect a proposed connection, compare a safe draft, or understand a check result. It is deliberately separate from permission to run work.
Check whether the declared inputs and outputs of two tools fit together, and identify missing information before any downstream work begins.
Request a compatibility report for a proposed workflow without starting work, spending execution capacity or granting any new permission.
Compare safe drafts or receive a starting plan that a person can review and correct. It never reveals private implementation details or grants authority.
Read your own bounded status and a practical explanation without disclosing another account's request, payload, credentials or private evidence.
Webhook Boundary connects declared webhook source profiles to predeclared HTTPS sandbox destinations, verifies each request, converts accepted JSON into a consistent event format, and returns redacted operational evidence.
Repository changes, billing changes, team chat messages, form submissions and monitoring alerts. We can agree up to eight exact source profiles for one pilot.
Signed-request verification (HMAC), exact route and method checks, JSON and body-size validation, stale-request and replay rejection, plus per-source rate and concurrency limits.
Declared field mappings turn accepted payloads into a consistent event, then deliver to one predeclared HTTPS sandbox destination with a bounded retry ceiling.
See source, classification, delivery outcome, retry count, timestamps and digests. Raw bodies, destination responses and credentials are not written to receipt history.
Agent Preflight gives approved AI-agent clients a read-only way to discover safe checks, review a proposed connection, compare or draft a plan, and read only their own status or explanation. The interface cannot approve work, run work, configure destinations or retrieve secrets.
A proposed connection should be understood before anyone decides what may happen next. The current private alpha checks only the declared contract and tool graph, then returns a deterministic, bounded compatibility result for review.
Agent Preflight checks declared tool interfaces and workflow graphs. It reports whether the bounded description is compatible, incompatible or needs review, including missing fields or an explicit adapter where applicable.
The private alpha does not execute customer workflows, handle customer secrets or payloads, grant runtime authority, sign or activate work, or provide controlled execution. A passing preflight remains a bounded result for a human or agent decision.
The wider Atom Flux direction may later connect approved contracts to signed, bounded execution and linked evidence. That is future platform direction, not part of the current private alpha and not implied by a compatible preflight.
Ordinary validation checks whether one message is shaped correctly. Agent Preflight checks whether a declared connection can be understood, checked and taken forward for review within explicit boundaries.
A passing result is not permission to run work. It is a clearer basis for deciding whether the connection should proceed to human review.
Teams repeatedly reconnect data sources, rewrite integrations, carry fragile assumptions between services and struggle to show why a workflow behaved as it did. The result is software that is expensive to change and hard to trust operationally.
Bespoke Glue Code: Ad-hoc translation scripts break silently when upstream payloads shift without typed notice.
Unbounded Tool Execution: LLM agents execute unverified tool-calls directly against production environments without runtime sandboxing.
Scattered Lineage: Post-mortem debugging relies on ambiguous log aggregators rather than cryptographically verifiable receipts.
Declared Workflows: Connections are reviewed before downstream work is considered.
Separate Approval: A connection check does not itself grant permission to run anything.
Receipt-Led Evidence: Redacted evidence helps teams review what happened and what to do next.
The goal is not to hide complexity. It is to make the important boundaries explicit, so workflows can be inspected, tested and improved without rebuilding the surrounding infrastructure each time.
Assemble reusable logic modules, declare required capability ports, and formulate workflow intent.
Verify typed interface compatibility, capability permissions, and resource constraints before launch.
Run approved workflows within declared operational boundaries.
Retain bounded receipts and operational evidence for human review.
The controlled Ingress Shield pilot edge is live in UK South and has passed its internal five-source acceptance gate. Pilot users can test real integration value with sandbox and pre-production traffic. Business-critical production workloads, contractual uptime commitments and open self-service remain outside the current pilot.
The first entry point is checking proposed AI-agent and API connections before they run. The wider direction is relevant wherever data, models and operational rules have to work together under real constraints: industrial analytics, automation, robotics, edge systems and other data-rich environments.
Checking declared tool and API connections before they request permission to run work.
Exploring controlled data-to-analysis workflows near operational equipment.
Exploring bounded workflows that need to operate near data sources under real constraints.
Maintaining structured evidence across multi-step data workflows for review and audit.
Ingress Shield is a controlled pilot with one surface for read-only agent connection checks and another for bounded webhook traffic.
Ingress Shield is WorkFoundry Ltd's controlled pilot with Agent Preflight for read-only AI-agent connection checks and Webhook Boundary for declared webhook traffic. Agent Preflight checks a proposed connection before action; Webhook Boundary verifies, validates and normalises declared requests before bounded delivery to one predeclared HTTPS sandbox destination, then produces redacted operational receipts for review. A compatible connection check does not grant permission to run work, change a destination, access secrets or make arbitrary network calls.
Ingress Shield checks that a request came from its declared source, validates the declared route, method and expected format, and applies bounded traffic limits. It rejects stale or repeated requests before delivery. The pilot records a redacted outcome for review rather than treating credentials, raw payloads or destination responses as routine diagnostics.
No. Ingress Shield runs on production-operated hosted infrastructure, but the current pilot is limited to sandbox and pre-production integrations. It is not approved for business-critical live workloads, does not provide a contractual uptime guarantee or SLA, and does not operate as an arbitrary relay or general destination-configuration service.
Pilot applications are reviewed manually. Send a public-safe description of the webhook source, AI-agent connection-checking use case and intended sandbox receiver. Do not send credentials, private endpoints, personal data or confidential payloads. WorkFoundry agrees the scope, data boundary and secure onboarding separately before any access is issued; this page is not a self-service access or key-request route.
MCP is a standard way for an AI assistant to request tools. An approved client can use WorkFoundry's account-bound, read-only interface to inspect a proposed tool connection or workflow plan, compare safe drafts, receive a starting plan for human review, and read only its own bounded result or explanation. The interface cannot approve or run work.
No. The read-only MCP interface cannot approve or start work, use paid execution capacity, configure a webhook destination, access secrets, sign or activate workflows, or make arbitrary network calls. It exists to check declared connections and explain bounded next actions before a separately reviewed decision to act.
The closed-pilot onboarding design uses Auth0-brokered Google or Microsoft browser sign-in. The protected MCP endpoint is deployed, but no external OAuth client, pilot invite, user account or browser-client acceptance has been completed. WorkFoundry does not receive provider passwords; the intended gateway record is pseudonymous rather than an email or profile record. An external identity will not itself grant access. Read current pilot privacy information.
We are selecting approved developers for a controlled pilot. Email a public-safe outline of either the AI-agent connection you want to preflight or the declared webhook route you want to protect; we will agree the data boundary and secure onboarding separately.
Pilot applications are reviewed manually. Secure key handoff happens only after the scope and sandbox boundary are agreed. Pilot privacy and access requests.