taskfloSECURITY / WRITTEN FOR THE REVIEWER
Designed for your security review. By construction.
The engine is designed to run in your account, under your keys, behind your network rules. This page explains the architecture for the person doing the review, not just the person requesting it.
01 / THE BOUNDARY
What crosses the boundary. All of it.
| Direction | What crosses | Control |
|---|---|---|
| Studio → customer registry → TFX | Signed workflow, pinned components and policy pack | The engine pulls and verifies the bundle. |
| Runtime → Studio, if enabled | Redacted metadata: version, status, duration and cost | Opt-in. No payload content. Authoring does not depend on it. |
02 / THE ARCHITECTURE
A boundary you can inspect.
Taskflo Studio
Design the work.
Declare its authority.
Review its bounds.
Pulled by your engine.
Taskflo Execution (TFX)
The engine runs the reviewed version.
Authorise → Comply → Execute → Attest
03 / SEVEN CONTROLS
The controls, in plain language.
No inbound vendor access
The engine pulls signed bundles from your registry. Review cloud permissions rather than accepting an assurance.
Customer-held encryption keys
Payload encryption is bound to your KMS or Key Vault. Review codec requirements and key policies.
One credential per action
A broker issues short-lived, scoped credentials. Secrets appear as references, not embedded values.
Declared network reach
Default-deny egress is bound to the systems declared by the workflow.
Isolated worker pools
Workflow logic, trusted tools and customer code have separate execution identities and network permissions.
Tamper-evident records
Hash-chained records and write-once exports make changes detectable. This is not a claim that alteration is impossible.
Signed, immutable bundles
Reviewers approve a version whose content can be verified before loading.
04 / WORKER SEPARATION
Separation that is structural.
The interpreter decides which step comes next, but cannot directly perform a tool call. Trusted tool workers receive only the authority required for the declared action. Customer components run without a cloud identity or network route.
That separation matters when a prompt, component or external response is hostile. The workflow’s orchestration process is not also the process holding the credential that changes a record. Test the isolation and the broker path in the target environment before production.
| Control | Interpreter workers | Trusted tool workers | Untrusted sandbox workers |
|---|---|---|---|
| Runs | Workflow logic only | Signed first-party and workspace components | Customer-written components |
| Network | Temporal only | Egress proxy; allowlist from bundle | None |
| Cloud identity | None | Brokered and short-lived | None |
| Isolation | Separate pool | Separate pool and identity | gVisor on AWS / Kata on Azure; CPU, memory and time caps |
05 / IDENTITY
Your identity provider. Your rules.
Named ownership
Every agent has a human owner, declared tools, data scope and autonomy.
Separation of duties
An initiator must not approve their own run.
Risk-scaled changes
Removing an approval gate requires a corresponding change review.
Default-deny authorisation
Cedar evaluates permissions before an action proceeds.
06 / REVIEW QUESTIONS
Ask the hard questions.
Does Taskflo process our runtime data?
The specification places runtime payload processing inside TFX in your cloud account. Studio handles workflow designs, not runtime payloads. Website enquiry data is separate; see the Trust centre.
Can Taskflo staff access our environment?
The specified architecture has no inbound support tunnel or standing vendor credential. Your engine pulls signed bundles from a registry you control. Deployment review should verify those boundaries.
Which models are used?
The architecture binds a model gateway to your cloud services. Regional availability, provider training terms and traffic paths must be reviewed for your deployment.
Where are the encryption keys?
The intended design keeps them in your KMS or Key Vault. Request the relevant key policies and permissions.
What if policy evaluation fails?
The intended production behaviour is fail closed: do not perform the action.
Can an agent reach an undeclared system?
Default-deny egress restricts tool traffic to the workflow’s declared systems. Model traffic uses the gateway inside the customer boundary; neither is a route through Taskflo.
How is custom code handled?
Customer-written components run in a separate sandbox pool without network or cloud identity, under hard CPU, memory and time limits. The isolation technology is a deployment-specific control to verify.
Can administrators alter records?
Tamper-evident does not mean impossible to alter. Hash-chain verification and write-once exports are designed to expose changes.
How does erasure work?
Content and audit metadata require separate retention and erasure designs. Review key destruction, backups and metadata with your privacy team.
Can telemetry be switched off?
Yes in the proposed architecture. Authoring remains independent of the optional runtime-metadata channel.
07 / PROGRAMME STATUS
Architecture is not a certification.
Independent penetration testing is planned before general availability and has not started. SOC 2 is on the roadmap; no completed report or certification is claimed.
Start a private review with the specification, trust boundaries and deployment controls. The architecture pack is assembled after a short call and mutual NDA, not delivered as an automatic download.
Request the security architecture pack.
Trust boundaries, worker isolation, key management, identity and the evidence model. Shared privately under NDA after a short call, with material assembled for your reviewers.
ONE WORKFLOW. A CLEAR NEXT STEP.
Bring your hardest reviewer.
Tell us about the process, the systems and the people. Let’s work through what it would take to run it.