Third-Party Runtime Boundaries#

Intended can govern third-party runtimes, but it does not inherit responsibility for every property of the upstream runtime.

Intended is responsible for#

• intent normalization into MIR
• customer policy evaluation
• signed authority decision tokens
• approval and escalation workflows
• immutable audit lineage inside Intended

The customer is responsible for#

• deploying and operating the third-party runtime
• reviewing generated policy before apply
• securing runtime credentials, hosts, and outbound destinations
• staging and change management for alpha or preview upstream software
• ensuring upstream runtime use complies with third-party terms

OpenShell / NemoClaw boundary#

For the current reference integration:

• Intended compiles policy YAML
• the customer applies the YAML with upstream tooling
• Intended does not remotely administer the upstream runtime by default
• Intended does not warrant that upstream alpha software is production-ready

Security review checklist#

• validate allowed endpoints before rollout
• require operator review for production scope
• keep fail-closed execution in downstream enforcement paths
• isolate runtime credentials from Intended API credentials
• test generated policy in staging first

Data handling boundary#

• customer-configured third-party runtimes are not Intended subprocessors merely because Intended compiles policy for them
• data processed directly by those runtimes remains subject to the customer's direct relationship with the upstream provider or target system
• Intended only processes the data required for its own authority evaluation, audit, and integration flows

Recommendation#

Treat reference integrations as governed entry points, not as a transfer of operational responsibility to Intended.

Related docs#

• OpenShell operations runbook
• OpenShell integration threat model