Bridle assumes requests can be malformed, stale, replayed, incompatible, or unauthorized. Each boundary is explicit, independently validated, and recorded.
A vendor can request a connection but cannot approve it. The customer authenticates, installs the Gateway, and controls activation, rotation, revocation, and removal.
The Gateway initiates TLS from the customer environment. Bridle requires no inbound listener, shared shell, or vendor-held infrastructure credential.
Requests name a versioned profile and constrained inputs. Arbitrary commands, raw manifests, and target-specific scripts are outside the contract and fail closed.
Every Gateway installation has its own cryptographic identity. Keys can be rotated or revoked without granting authority to another installation.
Authority, policy, entitlement, request integrity, freshness, and compatibility are checked before a request can reach execution.
Verification uses profile-specific evidence. Vendor projections disclose the outcome and safe receipt data, not customer secrets or unrestricted infrastructure state.
Retries do not convert an unknown result into success. Idempotency and recovery rules preserve the actual execution state until verification resolves it.
Staging and production use separate provider resources. Tenant-scoped records are protected with server authorization and forced PostgreSQL row-level security.
Gateway packages and hosted runtime images are built in CI, scanned, signed with Cosign, and promoted by immutable digest.