Private environment
Run Orkestr in a dedicated managed environment or infrastructure your organization controls.
SECURITY AND CONTROL
Your systems stay under your control.
Every project begins with explicit users, data, sources, systems, permissions, responsibilities, and operating boundaries.
HOW CONTROL WORKS
Approved information in. Reviewed action out.
The exact tools and rules differ by deployment, but the control pattern stays clear.
- TRIGGERIncoming customer request
A request arrives from an approved source.
- EMAILMessage and attachments read
The workflow identifies the request and required records.
- ERPOrder and account checked
Orkestr retrieves the operational record.
- CRMCustomer history gathered
Relevant context is added to the case.
- ORKESTRInformation reconciled
Rules, agent work, and exception handling run in one stateful process.
- MANAGER APPROVALDecision requested
The workflow pauses because the case exceeds its approved boundary.
- COMPLETIONERP updated and reply sent
The decision and every subsequent action remain in history.
Illustrative workflow using public-safe records. The systems, permissions, and approval points are configured per deployment.
THREE TRUST PRINCIPLES
Control is part of the process—not an afterthought.
Approved connections
Only configured accounts and services are available to the task. Access can be reviewed and revoked.
Human approval
Important actions can pause and wait for the right person before work continues.
CLEAR ACCESS BOUNDARIES
What Orkestr can—and cannot—work with.
Orkestr can
- Use tools and accounts explicitly connected for the task
- Follow configured steps and approval rules
- Pause work, surface warnings, and record decisions
- Show recent activity and process history
Orkestr is not authorized to
- Access systems that have not been connected and approved
- Treat one connection as unlimited access to a provider
- Ignore a configured human approval point
- Claim certification or compliance that has not been independently established
SECURITY FILES
Inspect the files behind the security claims.
These maintained public documents define reporting, authorization boundaries, public/private separation, and the latest dependency review.
SECURITY.mdSecurity policy & reportingSupported versions, responsible vulnerability reporting, and deployment responsibilities.docs/route-security-matrix.mdRoute authorization matrixPublic bootstrap, owner-scoped, and admin-only API surfaces with their enforcement points.docs/public-private-repository-boundary.mdPublic/private boundaryWhat belongs in the open-source core and what must stay in private deployment state.docs/dependency-security-review-2026-08-26.mdDependency security reviewA dated remediation record, audit result, validation gates, and rollback expectations.WHERE INFORMATION LIVES
Separate public software from private operations.
- Public core
- Generic product code, documentation, tests, and illustrative examples.
- Private environment
- Credentials, real configuration, browser and messaging sessions, and operational records.
- Connected services
- Information needed for the approved task, subject to the service provider’s own terms and controls.
REVIEW REQUIREMENTS
Security requirements stay concrete and reviewable.
- Certifications and regulatory requirements are assessed per deployment and documented when supported by evidence.
- Identity, retention, network policy, backups, and recovery must be reviewed for the chosen environment.
- Available connections and production readiness vary by deployment.
- Generated output and important actions need an appropriate human review policy.