Yodu team
Updated · 6 min read
AI employees become useful when they can work where the business already happens.
They become dangerous when “connect the tool” quietly means “give every role every action.”
Yodu separates the connection from the employee switch so a company can add capability without surrendering control.
Connect a business app once at the workspace level, then leave it switched on only for the AI employee that needs it. Access is one switch per employee: on means the employee sees and uses the tool, off means it is hidden entirely. Sending, publishing, spending, and destructive actions pause at the approval gate for a human decision. Test one known task before widening anything. A large integration catalog is useful only when access stays narrow.
Composio's public catalog lists more than 1,000 app integrations, including Gmail, Slack, GitHub, Notion, and Google Calendar. The number is useful, but it is not the goal.
The goal is one employee completing one job.
Before connecting anything, write:
For example:
Sales operator will read the founder's demo follow-up thread and prepare a reply. It may not send the email.
That brief tells you to connect Gmail, switch it on for the sales operator only, and let the approval gate hold the send.
| Layer | Question | | ----------------- | --------------------------------------------------------- | | App toolkit | What actions does the provider expose? | | Connected account | Which company account is authorized? | | Employee switch | Which AI employee can see and use that account? | | Approval gate | Which actions pause for a human decision before they run? |
Do not collapse these layers into one “connected” badge.
Open Tool access → App catalog. Search by provider or filter by category.
Select the add control and complete the provider's authorization flow. Then open Connected and confirm the intended account appears.
If the company uses multiple accounts, label them by purpose:
“Gmail connected” is not enough when the wrong inbox would expose customer or personal data.
Every connected app appears on each employee as a single switch, on by default. Open the employee's Skills & tools panel and switch the app off for every employee that does not need it.
The switch is binary and honest:
There is no per-tool autonomy mode to tune. Safety lives in the approval gate: anything external or irreversible, such as sending, posting, spending, or deleting, pauses for a human decision. You decide inline in chat or from the Approvals queue, with Allow once, This session, or Deny.
| Employee | First app | The gate will hold | First test | | -------------------- | ----------------- | --------------------------- | ------------------------------------ | | Research analyst | CRM or files | Nothing, the work reads | Build a sourced account brief | | Sales operator | Gmail | Email sends | Draft a follow-up to one test thread | | Support lead | Inbox or helpdesk | Outbound replies | Triage and draft one reply | | Content strategist | Docs or CMS | Publishing | Create a draft, not a published page | | Finance operator | Stripe | Refunds and billing changes | Read one subscription record | | Engineering operator | GitHub | Repository writes | Summarize one issue or PR |
Use for inbox context, triage, and drafts. Every send pauses at the approval gate; use Allow once until the workflow is repeatedly correct.
Use for meeting context and follow-up preparation. Start by reading schedules rather than modifying calendars.
Use for account context, deal notes, and draft updates. Separate read access from changes to lifecycle stages or source-of-truth fields.
Use transcripts and summaries as task inputs. Review what customer data is available before granting it broadly.
Use for research, enrichment, and outbound preparation. Keep paid enrichment, campaign changes, and external sends under review.
Use for issue, pull request, and repository context. Keep branch protection, required checks, and human merge control in GitHub.
Use read access for customer and subscription context. Refunds, cancellations, and billing changes pause at the approval gate.
Provider authorization belongs in the connected account flow. API keys belong in the relevant settings screen. An employee should receive a grant, not a raw credential pasted into chat or memory.
This follows a broader security principle: authorization should be scoped to the user and operation. OWASP's guidance for securing agentic applications treats excessive agency and weak tool boundaries as practical risks, not theoretical edge cases.
The first test should verify both usefulness and policy.
Check:
Track these manually during the beta:
| Metric | What it reveals | | ----------------------- | ---------------------------------------------------------- | | Successful scoped tests | Whether the connection works for the intended job | | Approval rate | Whether requested external actions are usually appropriate | | Wrong-account incidents | Whether account labels and grants are clear | | Reconnect frequency | Whether authorization is stable | | Unused enabled tools | Whether access is broader than the work needs | | Time blocked on access | Whether the employee was hired before its tools were ready |
The best tool setup is not the largest. It is the smallest set of well-labeled accounts and explicit grants that lets the team finish useful work.
Use the Composio connection guide, review the MCP server security checklist, then open MCP servers and AI tool integrations when the capability belongs to a private system rather than a catalog app.
Practical guides related to this workflow.
The trust architecture behind Yodu: one Docker container per workspace, command-queue-only access, keys you can rotate but never read, and an approval gate on every irreversible action.
Yodu team
A launch note on deleting draft-only, approval-required, autonomous, and revoked: three of the four tiers gated nothing, so tool access became one honest switch.
Yodu team
How to scope a remote MCP server, protect authorization, test health, review exposed tools, and roll access out to one AI employee at a time.
Yodu team
