No sandbox-escape claim
TrustRail does not prevent a zero-day, kernel exploit, or arbitrary code execution inside an agent runtime.
What TrustRail does not do
Security boundaries are useful only when their edges are visible. These limitations are part of the product contract, not legal footnotes.
Decision mode is not prevention
Decision mode gates your code, running in your process, with your credentials still in it. A compromised process can bypass the SDK, and guidance text returned to a model constrains an adversarial agent not at all. Only Enforce mode, where the gateway holds the credential, bounds what an agent can do.
No credential custody TrustRail never had
Enforce mode bounds actions using credentials TrustRail custodies. A credential the agent already holds, or one it finds, is outside that boundary entirely.
No network magic
Egress enforcement holds only when customer networking makes the broker the sole route out and live readiness probes pass.
The sole route out is not isolation from neighbours
The runtime attestation reports the broker as the only route off the workload's network segment. Hosts on that same segment are reached directly, without the broker, and the attestation does not report on them. Keeping a workload away from its neighbours is your platform's network policy.
Egress is decided once per connection
The broker decides a tunnel on its first request — the TLS server name, or the first HTTP Host — and pins the connection to the addresses it resolved. Later requests on a kept-alive connection are not re-read, so a second Host sent down the same tunnel reaches the same pinned address, as does domain fronting on a shared address over TLS.
No replacement for IAM or PAM
TrustRail consumes identities and credentials from those systems and governs consequential use above them.
No replacement for EDR, CNAPP, WAF, or service mesh
Those systems detect hosts, workloads, applications, and networks. TrustRail governs agent authority and provider effects.
No probabilistic authorization
Models may add evidence or tighten risk. They cannot override a deterministic deny or mandatory approval.
No exactly-once fairy tale
Networked side effects cannot be transport-level exactly once. TrustRail reserves idempotently, records UNKNOWN, and reconciles against provider evidence.
No automatic allowlist learning
Observe-mode destinations are proposals. Only a human may promote them, with expiry and audit evidence.
No compliance certification by implication
Controls and evidence can support an audit. They do not make a customer compliant or represent SOC 2, ISO, regulatory, or penetration-test approval.
No universal execution claim
DECISION_ONLY actions can be evaluated but are not executed by TrustRail. Only registry pairings with reviewed adapters are enforceable.
No general money detection
The live-money rule (a recorded human intent and two approvers for an amount through a live credential) covers connector actions only when the template declares an amount. TrustRail does not detect money movement in general: a custom template that moves money without declaring an amount is visible only to the second person who must review every custom template, and that review names each action that declares none.
No external-review fabrication
Internal tests, game days, and review documents remain internal evidence until a named independent party runs and signs its own assessment.