01
You decide which tools are enabled
The agent can use only connectors you explicitly install and enable. Disabled connectors do not expose their tools to the run.
Desktop AI You Can Inspect and Control
Choose which tools Think-Act can use, place consequential actions behind approval, and review supported activity after a run. Configure local, private, or cloud endpoints according to the workflow and your organization’s policy.
Enable only the tools you want
Pause before high-impact actions
Review supported run activity
Available for 64-bit Windows 10 and Windows 11. macOS is planned.
Think-Act ยท Security Center
Security Center
Illustrative control overview
Connector access
Only enabled tools are exposed
Action policy
Allow read
Ask to write
Block delete
Activity review
Inspect supported events after a run
Start bounded. Add access only when a workflow needs it.
Practical boundaries that keep the user in control
Think-Act limits automation through explicit tool availability, configurable action policies, reviewable activity, and deliberate endpoint choices.
02
Consequential actions can pause
Write, delete, network, and other supported actions can be placed behind confirmation so the workflow waits for your decision.
03
Unavailable tools stay unavailable
If a connector is disconnected or fails, its tools are removed from the agent’s available set until the connector is working and enabled again.
04
Skills cannot bypass missing tools
A skill describes how to approach a workflow. It cannot invent a connector or override tool availability and permission rules.
05
Runs leave evidence to review
Supported tool calls, observations, results, and approval events help you understand what happened before accepting a result.
06
Sensitive workflows need approved endpoints
For sensitive or regulated content, deliberately configure endpoints and connectors approved for the workflow rather than assuming desktop means private.
Tool permissions
Give each task only the tools it needs
Connectors expand what the agent can do. Think-Act exposes only tools from connectors that are enabled and connected. Disable anything the current task does not need, and remove servers that fail or behave unexpectedly.
Enable only what you need
Disable connectors the agent does not require for a task.
Gate write and delete actions
Keep destructive operations behind a confirmation step.
Block policy-violating tools
Commands or connectors that violate your rules can be blocked entirely.
Failed servers disappear
If a server fails, its tools are removed from the agent's available set.
Allow
The configured action may proceed automatically
Ask
Pauses for your approval before proceeding
Block
The configured action is refused by policy
Skills do not override these controls and cannot create a connector that is not installed.
Think-Act · Connector Permissions
Recommended starting policy
Read selected content
Keep the input scope visible
Create or change files
Review side effects before they happen
Send or publish
Confirm external communication
Delete or run risky commands
Limit difficult-to-recover actions
These are conservative recommendations, not a claim about one universal default. Match policy to the connector, data, and consequences involved.
Think-Act · Trust Confirmation
Connector security lifecycle
-
1
Discover
Identify the package, source, maintainer, and runtime.
-
2
Review and install
Inspect commands, arguments, variables, and requested access before confirming trust.
-
3
Enable and govern
Expose tools only when needed and apply Allow, Ask, or Block.
-
4
Review and remove
Inspect activity, then disable or remove access when the task no longer needs it.
Local MCP risk
Local packages run real code on your device
Before installing a local MCP server, remember that it runs as a process on your machine and can access whatever its runtime, permissions, and operating-system account expose. A Think-Act approval rule does not by itself sandbox the third-party process.
What a local MCP server may access
- Files, documents, and folders you expose to it
- Environment variables, credentials, or tokens it reads
- Network interfaces it can call from your machine
- Application data exposed to its runtime (Node.js, Python, npx)
- Third-party MCP packages are not controlled or audited by PixLab. Review the package source and maintainer before installing.
- Verify what environment variables and permissions a package requests before providing them.
- Think-Act requires explicit trust confirmation before a local server is installed.
- Disable or remove a server immediately if it behaves in unexpected ways.
Local MCP servers can be useful for filesystem access, developer tooling, and local integrations. Review the source, requested access, and runtime configuration before enabling one.
Data flow and processing
Know where your workflow data is processed and used
Think-Act runs on your desktop, but a workflow may still use configured model endpoints and connected tools. What leaves the device depends on the endpoint, connector, and context involved in that specific task.
-
1
You provide the context
A prompt, selected text, file, image, extracted document, or focused recording starts the workflow.
-
2
Think-Act prepares the task
The desktop workspace combines that context with the skills and enabled tools available to the run.
-
3
Configured services process it
Model context goes to the configured endpoint. Tool-specific context is shared only when the workflow calls an enabled connector.
-
4
You review the result
Inspect the output and supported activity evidence before saving, sharing, or accepting any resulting change.
Understand the difference
No connector required
Writing, OCR, document review, and recording can start without MCP. Model processing may still use the endpoint you configured.
Local MCP connector
The connector runs on your machine, but its own code and permissions determine what local data or network access it can use.
Local or private endpoint
A local or private endpoint must be deliberately configured and approved for the sensitivity of the workflow.
Approval & Recovery
Keep consequential actions reviewable and recoverable
Think-Act can pause before configured high-impact actions, surface activity after a run, and provide recovery controls where the workflow supports them. Review first, approve deliberately, and expand automation only after the workflow behaves as expected.
-
Step 01
Run the task with only enabled tools
Think-Act exposes only the connectors that are enabled and available for the run. Tools you have not enabled cannot be called, keeping the workflow bounded to the access you intentionally provided.
-
Step 02
Pause before consequential actions
When an action is configured to require confirmation, the workflow pauses before proceeding. Review the requested action, connector, and affected resource, then approve or deny it deliberately.
-
Step 03
Inspect what happened during the run
Review the supported activity evidence after execution. Check tool calls, observations, results, and approval events so you can understand what ran, what information was used, and whether the expected outcome was reached.
-
Step 04
Recover when the workflow supports it
Where checkpoints or recovery controls are available, return to an earlier state instead of blindly repeating a failed workflow. Keep actions that are difficult to reverse manual until the workflow has been tested enough to trust.
-
Step 05
Accept the result and reuse what proved reliable
Once the result and activity history match your expectations, accept the run. Reliable workflows can then be saved as local skills and repeated with the same tool and approval boundaries in place.
Accessibility & Safety
Security controls should work for every user
A warning that is hard to read, an approval prompt that cannot be reached by keyboard, or an unclear error makes a security control less useful. Accessibility is part of making automation understandable and controllable.
Keyboard
Contrast
Light & dark
Clear feedback
Security control checks
Warnings remain readable in every theme
Approval prompts, warnings, blocked actions, and error states should remain clear in both light and dark interfaces.
Critical controls are keyboard reachable
Approval dialogs, permission controls, and connector settings should remain operable without requiring pointer input.
Security state does not depend on color alone
Permission states, connector status, and warnings should remain understandable in high-contrast environments and when color differences are difficult to distinguish.
Errors explain what happened and what to do next
Connector failures, denied actions, and blocked operations should provide useful context instead of leaving the user with only a status code or generic failure message.
Accessibility does not weaken security controls. It helps users understand them, reach them, and make informed decisions when a workflow requires attention.
Start bounded. Expand only when the workflow needs it.
Begin with writing, OCR, document review, or screen recording. Add connector access only after the workflow requires it and you have reviewed the package and its permissions.
-
01
Begin without connectors
Use writing assistance, OCR, document review, recording, or pasted context before introducing tool access.
-
02
Review outputs and evidence
Treat agent output as something to verify. Compare extracted or generated content against the source and expected outcome.
-
03
Add one trusted connector
When a real workflow needs a tool, install one reviewed connector and keep consequential actions behind confirmation.
-
04
Expand only after it proves reliable
Review run history, save reliable workflows as skills, and widen automation gradually rather than all at once.
Enterprise direction
Review Current Security Controls
Planned controls for managed deployments
Think-Act’s current focus is on reliable local workflows, connector permissions, approvals, and activity review. Broader organization-level controls are planned after those foundations are proven stable.
These are roadmap items, not current product capabilities. They should not be relied on when evaluating Think-Act security today.
Planned
Managed installers & updates
Admin-controlled installation and update policies for managed devices.
Planned
Admin-approved connector registry
Organization-level control over which connectors users can install.
Planned
Cloud MCP connector gating
Controlled access to cloud-hosted connectors using the same security model.
Planned
Least-privilege worker accounts
Reduced-privilege Windows accounts for higher-risk local tool execution.
Planned
A2A remote agents
Delegation to trusted remote agents after the connector security layer has proven stable.
FAQ
Common questions about security
Answers to the most common security, privacy, and permissions questions. More product questions are covered on the full FAQ page.
Try Think-Act for WindowsAre MCP tools safe by default?
No. Local MCP servers run code on your device and are not audited or controlled by PixLab. Install only packages from sources you trust, verify their permissions and runtime requirements, and keep risky tool actions behind confirmation. Review the integration model before adding a package.
Can Think-Act use private or local endpoints?
Yes, where configured. Sensitive workflows should use approved local or private model endpoints. This requires deliberate setup aligned with your organization’s data governance policy. Private endpoints are not configured by default; review the data handling guidance before processing sensitive content.
Does using the desktop app mean all processing stays local?
No. Think-Act runs as a desktop application, but processing depends on the model endpoint you configure and the connectors used by the workflow. A local MCP server runs on the device but may still make network calls according to its own code and permissions. See the data-flow overview.
Can every Think-Act workflow run offline?
Do not assume that connector-free means offline. Internet requirements depend on the configured model endpoint, connector runtime, sign-in, and other services involved in the workflow. Confirm the complete data path before relying on offline operation.
What happens when a connector fails?
A failed connector is disabled and its tools are removed from the available list until the user fixes and re-enables it. Think-Act does not assume those tools remain available. See tool permissions for the Allow, Ask, and Block model.
Does Think-Act take actions without my approval?
Security policy determines what may run automatically. You decide which tools are enabled and which actions require explicit confirmation. Keep write, delete, and other high-impact actions set to “Ask” while validating a workflow. The approval and recovery workflow shows what to inspect before accepting a result. For a practical rollout pattern, follow the bounded automation guidance.
Are enterprise security features available now?
The current release includes per-user connector controls, Allow, Ask, and Block rules for supported actions, and activity review. Managed installers, admin-approved connector registries, cloud MCP gating, A2A remote agents, and least-privilege worker accounts remain roadmap items. See current and planned team controls for details.
How do I check what the agent did during a run?
Review the activity log, tool observations, and reported tool events accessible after each run. A clear success criterion set before the run helps you verify whether the requested outcome was actually reached. See the desktop agent documentation for more detail.
Explore Think-Act
Free to download · Review-first workflow
Start with a bounded task. Add access only when needed.
Individuals can begin with writing, OCR, document review, or screen recording. Teams can review current Business options and discuss deployment requirements before standardizing a workflow.