No-Code SaaS Automation Platform · View 19 of 21 · Assurance
Decisions
- The connector sandbox sits in the application zone with no credential in scope beyond the single connection it serves, a CPU and wall-clock ceiling, no filesystem persistence, and egress only to the hosts its manifest declares.
- Custody is a zone of its own, reached only by token exchange at the egress boundary. The runner never holds a credential it could reuse, and the refresh token never leaves the zone.
- Provider responses crossing inward are untrusted input: schema-validated, size-bounded, and unable to influence an automation's control flow.
Threats designed against
- Server-side request forgery through a generic HTTP step: author-supplied URLs are resolved and checked against internal, link-local and metadata ranges, and re-checked after every redirect.
- Unauthenticated push: a delivery without a valid per-connection signature is rejected before it reaches the event log.
- Credential exfiltration via logs: plaintext never appears in logs, run history, error messages or the ledger, and that is a zero-tolerance assertion.
Risks
- Catch-hooks and platform-hosted mail addresses are public endpoints by design, and are the most exposed surface in the set.
- Partner connector code in the sandbox is the largest residual risk, and Core Architecture Question 7 is whether to accept it at all.