Machine identities
Machine identities let an Organization give an agent mutual-TLS access to an HTTPS service without giving the agent the private key. The trusted application transport chooses and loads the certificate after checking the agent, destination, HTTP method, and path policy.
Owners, Admins, and Security Admins manage identities. Auditors can inspect metadata and health but cannot change policy. Agent Admins, members, and viewers do not receive access.
Provision an identity
Open Governance → Access → Machine identities and choose the rollback retention period first; the page's setup checklist shows the next step until everything is configured. Upload either:
- A PEM certificate chain and matching PEM private key, with an optional import password.
- One PKCS#12 (
.p12or.pfx) bundle, with an optional import password.
The import password is used only while parsing the upload. The platform normalizes the material, verifies that the deployment's OpenSSL policy can load it, encrypts it, and then shows certificate metadata for review. Activate the staged version after checking the fingerprint, subject, issuer, validity dates, and key type.
Define the destination
A destination consists of a hostname pattern, port, network policy, and trust policy. Exact hostnames and one-label wildcards such as *.example.com are supported. The wildcard does not cover the apex or deeper subdomains.
Public destinations must resolve entirely to globally routable addresses. Private destinations require explicit CIDRs that are also inside the deployment operator’s private-network allowlist and outside its mandatory platform-network denylist. IP-literal URLs, metadata endpoints, loopback, link-local, multicast, and unspecified ranges are prohibited.
System trust is used by default. If you upload a custom CA bundle, it replaces system trust for that destination.
Grant an agent access
Choose one identity, destination, and agent, then provide the allowed HTTP methods and path prefixes. Prefixes are boundary-aware: /api includes /api and /api/reports, but not /apix.
The grant applies automatically to ordinary http_request calls and Organization OpenAPI calls. It combines with existing API-key, bearer, Basic, or OAuth authentication. The agent does not choose or receive a certificate handle.
If a managed destination has no matching grant, multiple policies match, the feature is disabled, or the active certificate is unavailable, the request is blocked before network access. It never retries without the certificate.
Rotate, test, and revoke
Upload a new version and activate it to cut over transactionally. The previous private key is retained only for the Organization’s configured zero-to-thirty-day rollback period. A rollback is possible only while that key remains present and the certificate is still valid.
Connection testing opens the policy-proxy tunnel and completes a TLS handshake without sending an HTTP request. TLS 1.3 tests also check the server's response to the client certificate. If the server rejects it, the test fails. If acceptance cannot be confirmed, such as when the server disables session tickets, the console shows client certificate acceptance unverified. Use an authorized API request to confirm access in that case. Normal agent traffic also updates passive health metadata.
The TLS 1.3 confirmation check follows the session-ticket ordering in RFC 8446, section 4.6.1.
Emergency revocation is irreversible: it disables grants and erases active and retained private keys immediately. An already-established TLS connection may finish, but no new connection can use the identity.
Active certificate expiry warnings appear in the console and are emailed at 30, 14, 7, and 1 day. Every policy change and connection test appears in Organization security activity, while every agent certificate attempt and outcome appears in Agent Audit.