Connection ACLs, and the demo that runs itself
Restrict any source to specific members — enforced in chat and search as an intersection, never a leak. Plus e2e:demo — the full briefing + CRM sweep as an executable test, passing 9/9 against live production data.
Two ships that make a multi-user deployment trustworthy.
Restrict any connection to specific people
A source can now declare who may retrieve from it:
# workspace/<org>/sources/gmail.yaml
access:
visibility: restricted
users: [chris@metacto.com]
Enforcement is an intersection at query time — the agent's configured scope ∩ the requesting
member's grants — applied in every user-facing read: chat (search_knowledge), the Search page
(queries and the default browse), everywhere. A member without the grant doesn't see an error;
the restricted source is simply invisible — zero rows in browse, empty on direct filter, and an
agent asked to "search our gmail" comes back empty-handed while every other source stays fully
searchable. An empty intersection returns nothing rather than leaking.
Scheduled team runs (the morning briefing, the CRM sweep) keep their configured access: the team reads the restricted inbox, and its curated outputs — briefs, scored proposals in the review queue — are the surface everyone else sees. That's the point of the design: raw data stays scoped, judgment flows to the team.
The demo is now an executable test
npm run e2e:demo fires the two flagship checks exactly as their automations do, waits, and
asserts demo-worthiness: the briefing covers leads, opportunities, and today's moves with real
substance; sweep proposals ride the review queue with confidence envelopes and are never
auto-applied.
Today's rehearsal against a live production deployment: 9/9 — the briefing completed in 227s, and the sweep found four real movements in the morning's mail and queued them as scored proposals (88%, 82%, 75%…) for one-click human review. The same run doubles as the regression gate: if a release breaks the loop, the scorecard says exactly where.