01
Identity
Every run is tied to a project and an end-user identity so private work stays scoped.
ChuskySecurity
Boundaries you can
reason about.
Chusky is designed for work that crosses conversations, tools, files, and real-world actions. Security is the set of boundaries that keeps those transitions understandable.
Security model
Identity, capability, context, and approval meet at the run.
A request is not a blank cheque. The workspace, end-user identity, enabled capabilities, and approval state all shape what the agent may do.
02
Capability
Connected apps and native actions are made available intentionally, not assumed.
03
Context
Files, notes, threads, and memories belong to the workspace that owns them.
04
Approval
Consequential actions can pause for an exact, expiring decision before execution.
Limits that travel with the work
A budget, a record, and your decision.
Whether a job starts in a message, a meeting, a phone call, or a scheduled check-in, important actions need understandable limits.
Your approval for important changes.
Spending, deleting, and high-impact sends wait for the owner’s yes. Review the exact action and its target. The approval is tied to that request, rather than a general permission to do anything.
A trail you can follow.
Every run has a budget and an audit trail. Longer missions keep their steps, progress, and supporting evidence together so you can inspect what happened and what is still waiting.
Choose the reach
A scheduled check is still your choice.
Attention Pulse checks the inbox, calendar, and watches you enable. Event-triggered work follows the sources and actions you configure. Connecting an app does not automatically ask Chusky to watch everything in it.
Private and shared context.
A linked private channel and a team conversation have different audiences. Keep each request tied to the right workspace and identity when moving between channels.
Visitors and other agents.
A business chat widget, MCP host, or A2A caller is an entry point. Available tools and account access still need to be scoped to the person or system behind the request.
Practical guidance
Keep the trusted boundary where you control it.
Use server-side routes for project keys, derive end-user identity from your own session, and show users the state of work instead of hiding it behind a spinner.
For workspace owners
- Review connected apps and channels regularly.
- Use approvals for actions that affect other people or systems.
- Remove devices and connections when access is no longer needed.
For developers
- Keep keys out of browser code and public logs.
- Persist thread and run IDs in your own trusted backend.
- Handle disconnected streams as recoverable state.