KHUM

Connect every business system. Keep every AI action under your control.

Comment

Inspiration

KHUM began with a frustrating experience inside a real clinic.

While helping the clinic set up an AI workflow, we discovered that its own customer, appointment, and operational data was locked inside a third-party ERP system. To let AI retrieve that data and reduce repetitive work, the clinic had to request API access from the software provider—and pay an additional fee—just to access data generated by its own business.

That experience revealed a much larger problem.

Businesses operate across ERPs, CRMs, property-management systems, spreadsheets, databases, email, messaging platforms, and many other applications. However, most of these systems were designed before AI agents and MCP became part of everyday work.

When a business wants its employees to work through AI, it faces a difficult choice:

  • Give employees access to sensitive API credentials.
  • Build a separate integration for every AI workflow.
  • Depend on software vendors to provide access.
  • Or allow AI to operate without sufficient control, visibility, and accountability.

We believe employees should be able to use the capabilities unlocked by business API connections without ever receiving, copying, or exposing the underlying API keys.

The business should remain in control of its data, permissions, budget, and actions.

That idea became KHUM. In Thai, “Khum” means to control.

What it does

KHUM is an industry-agnostic Business AI Control Plane that sits between AI agents, employees, and the software systems a business already uses.

An administrator connects the organization’s APIs, remote MCP servers, and databases to KHUM once. Credentials remain protected inside the platform and are never exposed to employees or AI clients.

The administrator can then create an Access Hub for any department, branch, team, project, or responsibility—for example:

  • Clinic Reception
  • Medical Operations
  • Finance
  • Hotel Front Office
  • Hotel Management
  • Sales
  • Human Resources

Each hub receives only the tools, systems, data fields, and actions required for its work.

Employees sign in using their own identities and interact through a compatible general-purpose AI agent. KHUM evaluates every request against the employee’s role, organizational scope, hub permissions, data policy, and budget before allowing it to reach an external system.

For read operations, KHUM returns only authorized information.

For actions that change data, send messages, create documents, or affect business operations, KHUM generates an exact preview and sends it through a human approval process before execution.

Every request produces an audit trail showing:

  • Who requested it
  • Which AI client initiated it
  • Which hub and business system were involved
  • What data was accessed
  • What action was proposed
  • Who approved or rejected it
  • What the final verified outcome was
  • How much the operation cost

On the web dashboard, KHUM uses WebMCP as the human–agent interaction layer. The page can dynamically expose only the tools available to the currently authenticated employee and their active hub. The browser agent can therefore perform structured operations inside the visible KHUM interface while the user retains context and control.

Behind that interface, KHUM connects to traditional REST APIs, OpenAPI services, remote MCP servers, and approved business databases.

In short, KHUM gives employees one governed AI interface while allowing the business to control every underlying connection.

How we built it

We started by mapping the real clinic workflow that inspired the project: where information was created, which third-party system stored it, who needed access, and where AI could reduce repetitive work.

From that workflow, we designed KHUM around five core layers:

  1. Connection layer
    Connects business APIs, remote MCP servers, and approved database sources while keeping credentials on the server.

  2. Identity and policy layer
    evaluates the organization, user, role, department, hub, requested tool, data scope, and budget for every operation.

  3. WebMCP interaction layer
    exposes structured, context-aware tools to browser agents through the KHUM web interface instead of forcing agents to guess how to operate the UI.

  4. Approval and execution layer
    converts sensitive write operations into immutable previews, routes them to authorized approvers, rechecks policy before execution, and verifies the result.

  5. Audit and budget layer
    records access, actions, approvals, costs, errors, and uncertain outcomes in a searchable audit trail.

We designed logical MCP and WebMCP surfaces around each Access Hub. This allows one organization to support many departments without deploying and maintaining a separate physical server for every team.

We also created the first two industry packs:

  • Clinic Operations, focused on appointments, customer information, operational documents, and controlled communication.
  • Hotel Operations, focused on reservations, daily reporting, occupancy information, documents, and management summaries.

The current prototype validates KHUM’s product model, policy boundaries, approval lifecycle, data flows, and human–agent experience through an interactive architecture and workflow prototype. The next implementation milestone is a connector-backed pilot using synthetic data before introducing real customer credentials.

Challenges we ran into

The hardest challenge was not connecting APIs. It was deciding what should happen after they were connected.

A single shared integration must still produce different capabilities for different people. A receptionist, accountant, hotel manager, and business owner should not receive the same tools or see the same data simply because they belong to the same organization.

Another challenge was designing safe write operations. A basic confirmation button is not enough. The approver must see the exact action and payload that will be executed. If the source data or policy changes after the preview is created, the request should be invalidated and reviewed again.

External APIs also do not always provide reliable exactly-once execution. A request can time out even though the external system has already processed it. KHUM therefore treats uncertainty as a real system state. It never blindly retries an ambiguous business action.

Finally, WebMCP and backend MCP solve different parts of the problem. WebMCP enables a shared browser experience between a person, a web application, and an agent, while backend integrations connect to external services. Designing KHUM required combining both without weakening the organization’s security boundary.

Accomplishments that we're proud of

We are proud that KHUM grew from a real operational problem rather than a hypothetical AI use case.

We created a model where:

  • Employees can use business systems through AI without handling API keys.
  • One organization can create different AI capabilities for any department or team.
  • The tools visible to an AI agent change according to the authenticated user and active business context.
  • Sensitive actions remain under human control.
  • Every AI operation can be traced back to a person, policy, system, and outcome.
  • Unknown or ambiguous results are escalated instead of silently retried.
  • The same core platform can support both clinics and hotels without becoming an ERP, CRM, or industry-specific application.

Most importantly, KHUM does not ask businesses to replace all of their existing software. It gives them a governed layer above those systems so they can safely participate in the AI-agent era.

What we learned

We learned that owning data is not the same as being able to use it.

A business may legally own its customer and operational information while still being technically dependent on another vendor to access it.

We also learned that the number of connectors is not the most important differentiator. The real value lies in deciding:

  • Who can use each connection
  • What information they can access
  • Which actions require approval
  • How much they are allowed to spend
  • How every decision can be audited

AI identity is also not business authority. An AI agent may know what a user wants, but KHUM must independently verify whether that person is authorized to perform the requested operation.

Finally, we learned that human-in-the-loop design is most useful when the human remains inside the real workflow. WebMCP provides an important foundation for this by allowing agents to operate through structured tools while preserving the visible web interface, authentication state, and shared context.

What's next for KHUM

Our next step is to turn the architecture prototype into a working pilot with synthetic clinic and hotel data.

The first release will focus on a narrow but complete flow:

  1. An organization administrator creates departments and Access Hubs.
  2. The administrator connects an approved business system.
  3. Employees sign in individually.
  4. WebMCP exposes only the tools allowed for that employee’s current hub.
  5. Employees perform read-only work through an AI agent.
  6. One controlled write operation is submitted for human approval.
  7. KHUM executes, verifies, and records the final outcome.

After validating tenant isolation, permissions, approval safety, and audit completeness, we will run supervised pilots with real clinic and hotel teams.

Our long-term vision is for KHUM to become the standard control layer between businesses and AI: one place where organizations can connect their systems, distribute capabilities, protect credentials, govern actions, control costs, and remain the true owners of how their data is used.

Built With

  • cluade
  • codex
  • render
  • supabase
  • webhook
Share this project:

Updates

Submission history