CIS
Overview
Enable Cisco ThousandEyes Enterprise Agents to securely retrieve credentials from Secrets Management at test runtime, without storing secrets in the ThousandEyes platform.
Customer problem
Enterprises running digital experience monitoring often need to authenticate synthetic tests (HTTP, Page Load, Transaction, API) against protected applications. That requires storing credentials somewhere. Security and compliance teams don't want those credentials duplicated inside a monitoring platform, where they add to the audit surface, complicate rotation, and create another place a secret can leak. Many organizations mandate that credentials live only in a dedicated secrets manager, which historically forced a tradeoff between monitoring coverage and their secrets-management policy.
Solution
ThousandEyes integrates directly with Secrets Manager, Self-Hosted so credentials never have to be stored in ThousandEyes. Instead of holding a static secret, a test references a credential in the vault. At test execution time, the ThousandEyes Enterprise Agent retrieves the secret from Idira over an SSL-verified connection, injects it into the test, and discards it. Secrets stay under Idira's control and existing rotation policies, while ThousandEyes gets the access it needs to run authenticated tests. This lets customers keep full monitoring coverage without weakening their secrets-management posture.
Key benefits
-Secrets stay in Idira, never in ThousandEyes. Credentials are retrieved at runtime from Idira Secrets Manager, Self-Hosted and are never persisted in the ThousandEyes platform. -Runtime retrieval by the Enterprise Agent. The ThousandEyes Enterprise Agent fetches the secret from the vault at the moment a test runs and injects it into the request, so the credential is not exposed in test configuration or results. -Simple one-time setup. Customers connect ThousandEyes to their Idira vault once using host ID and API key authentication, then point each test at the specific secret it needs by referencing a friendly credential name instead of the full vault path. -Works across authenticated test types. Vault-backed credentials can be used in HTTP Server, Page Load, Transaction, and API tests, covering the authentication scenarios customers monitor most. -Enforced SSL verification and centralized rotation. The agent's vault connection always verifies SSL, and because secrets live only in Idira, rotation and access control stay centralized under the customer's existing policies.
No version information available.
We also recommend
IDI
Enable custom name for SRS platforms
Securely retrieve privileged credentials required by Claroty
SEC
Securely connect to variety of systems using privileged accounts required by SecuPi Data Security Platform