OrgRelay
orgrelay.com

Security requirements

A connector gives an AI a path into a company's systems. These are the rules that keep that path narrow. Most of them are checked automatically by the self-test tool; the rest are yours to review.

OrgRelay itself enforces roles, approvals and logging before a request reaches you. Those controls are described for business readers on orgrelay.com/security. This page covers your side.

1. Tenant isolation

  • Decide the tenant from the token, never from a request field. See authentication.
  • Every query filters by tenant first. This includes lookups by id: orders.get with another company's order number returns not_found.
  • Caches, idempotency stores and search indexes are keyed by tenant too. A shared cache keyed only by order_no is the classic leak.

The self-test runs each read tool with two tenants' tokens and fails on any overlap. Multi-tenant MCP servers are a common source of data leaks, so treat this check as mandatory even for single-customer deployments.

2. Least privilege

  • Expose only what OrgRelay needs for the questions staff actually ask. Three to five read tools is a good first version.
  • Leave out by default: ID numbers, bank account and card numbers, salaries, passwords, API secrets. The standard HR tools deliberately omit them.
  • If a customer needs sensitive fields, put them in a separate tool. The owner can then grant it to specific roles only or switch it off.
  • Prefer a token that can only read when you ship only read tools.

3. Write tools

  • Mark them write and keep readOnlyHint consistent. See the connector spec.
  • Honour idempotency keys. See approvals and write tools.
  • Re-check permissions and record state at execution time. Approval in OrgRelay is not a substitute for your own checks.
  • Bound the blast radius: one record per call, sensible limits on quantities and amounts.

4. Logs

  • Never log tokens, passwords or full card numbers. Mask sensitive arguments.
  • Do log orgrelay/actor and the approval id with each change, so your audit trail names a person.
  • Keep logs on infrastructure the customer controls.

5. Error messages

Messages are shown to staff and passed to the AI. They must not contain:

  • stack traces or exception class names
  • SQL, query fragments or table names
  • file paths or server hostnames
  • versions of your server software
  • tokens or any part of them

Write what a person can act on: "Order SO-1002 has shipped and cannot be cancelled." Codes are in the connector spec. The self-test flags common leak patterns.

6. Transport

  • HTTPS with TLS 1.2 or later whenever traffic leaves the LAN.
  • No redirects; OrgRelay does not follow them.
  • Request bodies around 1 MB maximum.
  • Rate-limit with 429 and Retry-After rather than dropping connections.

7. Input validation

  • Validate every argument against your inputSchema. The templates include a minimal validator; production code can use a schema library.
  • Never concatenate arguments into SQL. Use parameters.
  • Treat free-text arguments as untrusted: the AI writes them, and the AI was prompted by a person and by documents that may contain hostile text.

8. Network placement

OrgRelay is installed on the company's own Mac mini, usually in the same network as the systems it reads. Put your connector there too and use an internal address. If the system lives elsewhere, connect through a VPN or a reverse proxy with its own authentication. An IP allow-list for the OrgRelay machine is supported; see authentication.

9. Events

The summary of an event is forwarded verbatim to chat apps. Keep personal data out of it and put ids in data. Sign every event and keep your clock accurate; OrgRelay rejects signatures more than five minutes old.

10. Versioning as a security property

Never turn a read tool into a write tool under the same name. Owners grant tools by name, and an owner who allowed orders.search for all staff did not agree to anything that changes data. Add a new tool instead, as the versioning rules require.

Checklist before delivery

Check How
Tenant isolation --token and --token-b in the self-test
No leaks in errors Self-test, then read a few errors yourself
Write tools idempotent Self-test --write on a test system
readOnlyHint consistent Self-test
Secrets not logged Grep your logs for a known token
Sensitive fields isolated Review tool outputs against section 2

Common questions

How is tenant isolation tested? Two tokens, every read tool, any overlap fails.

Salaries or ID numbers? Not by default. A separate, restricted tool if truly needed.

Where should the connector run? Next to the system, on the customer's LAN.

Next

  • Quickstart: run a template and pass the self-test in 15 minutes.
  • MCP overview: OrgRelay as an MCP server for staff.

Updated (Singapore time) · OrgRelay Team