No sandbox-escape claim
TrustRail does not prevent a zero-day, kernel exploit, or arbitrary code execution inside an agent runtime.
Security boundaries are useful only when their edges are visible. These limitations are part of the product contract, not legal footnotes.
TrustRail does not prevent a zero-day, kernel exploit, or arbitrary code execution inside an agent runtime.
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.
Enforce mode bounds actions using credentials TrustRail custodies. A credential the agent already holds, or one it finds, is outside that boundary entirely.
Egress enforcement holds only when customer networking makes the broker the sole route out and live readiness probes pass.
TrustRail consumes identities and credentials from those systems and governs consequential use above them.
Those systems detect hosts, workloads, applications, and networks. TrustRail governs agent authority and provider effects.
Models may add evidence or tighten risk. They cannot override a deterministic deny or mandatory approval.
Networked side effects cannot be transport-level exactly once. TrustRail reserves idempotently, records UNKNOWN, and reconciles against provider evidence.
Observe-mode destinations are proposals. Only a human may promote them, with expiry and audit evidence.
Controls and evidence can support an audit. They do not make a customer compliant or represent SOC 2, ISO, regulatory, or penetration-test approval.
DECISION_ONLY actions can be evaluated but are not executed by TrustRail. Only registry pairings with reviewed adapters are enforceable.
Internal tests, game days, and review documents remain internal evidence until a named independent party runs and signs its own assessment.