Skip to main content
OrgX is designed around workspace-scoped access, explicit authorization, and reviewable work records. This page describes the controls and boundaries in the published product surfaces. It is not a compliance attestation, security questionnaire, or promise about a provider connected to OrgX.

​
What OrgX receives

  • Hosted MCP receives the tool arguments your client sends and returns tool results. These can include prompts, queries, decisions, artifact text or links, and workspace identifiers.
  • OrgX also handles account, connection, authorization, and operational records needed to run the service. A browser-only trial is not offline or zero-data-retention.

​
Local hooks are a separate integration

  • Adding the hosted MCP URL in a browser client does not install the OrgX wizard, local plugins, or session hooks. Do not enable other connectors or upload real files for the synthetic-data trial.
  • Local wizard and plugin setup can change client configuration and install capture hooks. Depending on the client and enabled capture, records can include session IDs, working-directory and transcript paths, timestamps, event and tool counts, summaries, and work context. Review the specific integration before installing it on a machine containing employer code.

​
Retention policy

  • Durable workspace records remain until removed through an authorized product workflow, a workspace deletion request, or an applicable retention policy. Do not assume trial records expire automatically.
  • Connection state, operational logs, and provider backups have separate lifecycles. This public summary does not establish a fixed retention period for those classes; request the current deployment-specific details before sending sensitive data.

​
Disconnecting and deleting data

  • Disconnect the client and revoke the relevant credentials to stop future access. This does not delete records already stored in OrgX or copies held by your AI provider.
  • Review and delete the trial records through authorized OrgX tools or request workspace deletion through support. Ask for confirmation of the scope and remaining backup or provider copies. This summary does not promise a hard-delete completion time.

​
Encryption and evidence

  • The hosted MCP endpoint uses HTTPS. The privacy policy describes TLS in transit and encryption at rest where supported by the underlying provider. This is not end-to-end encryption: OrgX and the services processing a request can process its content.
  • A specific TLS version, storage cipher, backup schedule, recovery-drill cadence, or deletion SLA requires current deployment evidence. This page is not a compliance attestation; request that evidence at security@useorgx.com before a work-data evaluation.
See what survives a fresh conversation.

​
Security boundaries

The public surfaces use clear protocol and endpoint boundaries: See Authentication for the current credential and header contract.

​
Authorization and least privilege

  • API keys and MCP sessions are evaluated in an authenticated workspace context. Do not put a user_id in a request to select another identity.
  • MCP tools declare the scopes they require. A client should request only the tools and provider permissions needed for the workflow.
  • Agent actions are subject to the configured tool, scope, budget, and approval policy. A recorded approval is a human decision; it is not proof that an external provider accepted, merged, deployed, published, or paid for the work.
  • External MCP servers and connected providers keep their own authorization, storage, and retention contracts. OrgX cannot attest to controls outside the OrgX surfaces it operates.

​
What OrgX records

Depending on the surface and the workspace configuration, OrgX may record:
  • work items, status updates, plans, blockers, decisions, and handoffs;
  • artifact metadata and links to customer-owned or provider-hosted content;
  • execution receipts and available evidence for eligible actions;
  • authentication, authorization, and operational events needed to run and support the service.
These records are not interchangeable. A producer status, approval, receipt, provider response, and independently verified outcome represent different states. The docs use the narrowest state supported by the underlying surface.

​
Private model reasoning

OrgX does not publish private model chain-of-thought or provider reasoning summaries. Public clients receive observable progress, material findings, concise rationale summaries, evidence, blockers, and decisions. Do not treat a status message or rationale summary as a transcript of model deliberation.

​
Credentials and connected data

  • Treat API keys, OAuth tokens, session cookies, provider credentials, and pairing URLs as secrets.
  • Keep credentials out of browser bundles, public repositories, screenshots, logs, prompts, and artifacts.
  • Revoke a key or disconnect a provider when it is no longer needed. Reconnect only after checking the requested scopes.
  • For external MCP providers, review that provider’s privacy, retention, and permission terms before sending workspace data.

​
Operational evidence

Documented API responses can include request or correlation identifiers. Retain those identifiers when investigating a failure or contacting support. The available activity, audit, receipt, and verification views depend on the surface and workspace configuration; do not assume that every operation has the same evidence fields.

​
Service boundaries

The following are not promises made by this page:
  • a particular cloud provider, region, encryption algorithm, transport version, backup schedule, or retention period;
  • a universal rate limit, uptime target, incident response time, or delivery guarantee;
  • SOC 2, HIPAA, GDPR, CCPA, or other compliance certification or attestation;
  • zero-data-retention treatment for OrgX or a connected model/provider;
  • security controls implemented by an external MCP server or provider.
Use the published API contract and current privacy terms for the specific surface. Enterprise security and data-processing questions should be handled through the current support or sales process rather than inferred from this overview.

​
Customer checklist

Use a dedicated workspace and request only the MCP tools, API scopes, and provider permissions required for the first workflow.
Check the requested action, rationale summary, evidence, scope, and destination. Approval records your judgment; confirm the external provider outcome separately.
Never paste API keys, OAuth tokens, cookies, one-time pairing URLs, or private provider responses into public documentation or shared artifacts.
Include the request ID, endpoint or MCP tool, workspace identifier, time, and a redacted error when reporting a problem. Do not send secrets or raw private model output.

​
Report a security issue

Report vulnerabilities to security@useorgx.com. Include a concise reproduction and only the minimum redacted evidence needed to investigate. Never include credentials or private model output in the report. For data-handling details, see the Privacy Policy.