AInforce
All posts
AI Agent Security August 14, 2026 8 min read

Agent Infrastructure in the Certificate Logs: What crt.sh Reveals Before an Attack

A network diagram showing TLS certificate transparency log entries branching into discovered AI agent subdomains, with some marked as unauthenticated and publicly accessible

The permanent record you didn't know you were keeping

Certificate transparency was introduced to make it impossible to issue fraudulent TLS certificates without detection. Every certificate issued by a public CA is logged to a set of public CT logs — append-only, tamper-evident, permanently accessible to anyone. The mechanism works: mis-issuance is much harder to hide than it was before CT. But the permanent, searchable nature of the log has a second consequence that most organisations deploying AI infrastructure haven't considered.

Every time an engineering team provisions a TLS certificate for an internal AI service — an agent orchestration endpoint, a RAG API, an MCP server, a staging inference environment — that certificate enters the CT log. The subdomain name is visible. The certificate dates are visible. The issuing authority is visible. The log cannot be edited or deleted. An attacker who queries crt.sh for your organisation's domain today can reconstruct the history of your AI infrastructure buildout: when services were stood up, when they were decommissioned, and what replaced them — often before you've announced any of it publicly.

CT logs as an AI infrastructure timeline

The certificate transparency record is not a snapshot — it's a history. A decommissioned service that had a public TLS certificate in 2024 is still enumerable in 2026. Subdomains like ai-staging.company.com, rag-v2.internal.company.com, and agent-test.company.com may no longer resolve — but they confirm that the infrastructure they served existed, which tells an attacker where to look for the production replacement.

What the scanner finds — and how to run it yourself

The PromptShield scanner queries crt.sh for all subdomains of a target domain and filters results for AI-specific naming patterns. The same query is runnable by anyone:

curl 'https://crt.sh/?q=%.example.com&output=json' | jq -r '.[].name_value' | sort -u | grep -Ei 'ai\.|agent\.|llm\.|rag\.|gpt\.|copilot\.|assistant\.|inference\.|embedding\.|mcp\.'

Run against a representative sample of enterprise domains, this query consistently surfaces patterns that warrant follow-up:

  • agent.company.com — an agent orchestration endpoint that received a public TLS certificate; may or may not still be live, but the infrastructure it served existed
  • rag.internal.company.com — a retrieval-augmented generation API, sometimes accessible at /docs (FastAPI's Swagger UI default) without authentication
  • llm-gateway.company.com — a self-hosted or proxied model serving endpoint; the name confirms an LLM gateway exists, the certificate dates indicate when it was stood up
  • mcp.company.com — a Model Context Protocol server; MCP servers grant tool access to connected agents, making unauthenticated exposure a high-severity finding
  • ai-staging.company.com — a staging inference environment; staging environments typically have the same model access as production but weaker access controls and less monitoring

Finding a subdomain in crt.sh tells you the certificate existed. It doesn't tell you the service is still live, what it's serving, or whether it requires authentication. Those answers come from the follow-up steps: DNS resolution (is the subdomain still resolving?), HTTP fingerprinting (what is the server returning?), and default path probing (/docs, /openapi.json, /health, /metrics). The CT log entry is the lead. The follow-up investigation determines whether it's a finding.

The FastAPI /docs pattern — why it matters in 2026

FastAPI, the Python web framework most commonly used to serve LLM and agent APIs, enables interactive API documentation at /docs by default. This is a Swagger UI that renders the full OpenAPI schema: every endpoint, every parameter, every response model. In development, it's invaluable. In production, it's a complete capability map served without authentication unless the developer explicitly disables it.

Security researchers have documented cases where production RAG and agent APIs — discoverable via CT logs or DNS enumeration — were serving their /docs endpoint publicly. The schema exposed by these endpoints goes well beyond endpoint names: it describes what data sources the agent queries, what tools it can invoke, and in some cases what parameters trigger specific workflows. For an attacker building targeted prompt injection payloads, a publicly accessible /docs endpoint removes most of the guesswork.

What an exposed /docs endpoint reveals

A FastAPI /docs page for a RAG agent might show: POST /query (retrieves from the document store), POST /tools/email (sends email on agent's behalf), POST /tools/crm (reads and writes CRM records). Each endpoint has parameter names, types, and descriptions. An attacker who reads this schema knows exactly which tool calls to target with a document-embedded injection payload — without ever authenticating or triggering an alert.

The same pattern has extended to MCP servers. The Model Context Protocol, whose adoption has grown substantially in 2026 as organisations give Claude and other models tool access to internal systems, defines a server that exposes a list of available tools to connected agents. MCP servers that receive public TLS certificates and are accessible without authentication expose not just an API schema but the full tool inventory: tool names, descriptions, input schemas, and in some implementations, recent call history. A publicly accessible MCP server is functionally equivalent to publishing your agent's capability manifest.

The certificate as a change management signal

Beyond active exploitation, the CT log has a less obvious use for defenders: it's an audit trail of infrastructure decisions that may have bypassed change management. In mature organisations, certificate issuance is gated on a review process. In practice, engineering teams building AI prototypes frequently provision certificates directly — through cloud provider certificate managers, through Certbot against a staging subdomain, through an internal CA configured for developer self-service — without a security review.

Querying crt.sh for your own domain and comparing the results against your known AI infrastructure inventory is a quick check for unreviewed deployments. Certificates issued for subdomains that aren't in the inventory represent infrastructure that exists outside normal change management — which typically also means outside normal monitoring, access control review, and incident response coverage. The CT log finds what the asset inventory missed.

CrowdStrike's Falcon AI platform includes an AI attack surface mapping module that performs similar enumeration from inside the network perimeter. The CT log approach is complementary: it maps what's externally visible before any authenticated access, from the same vantage point an attacker would use. Where Falcon sees the full internal topology, crt.sh sees what the internet sees — which is the relevant threat model for externally facing or misconfigured AI infrastructure.

Zero-trust implications

NIST SP 800-207 (Zero Trust Architecture) establishes that no network location should be implicitly trusted. For AI agent infrastructure, this principle has a specific implication: services should not be accessible based on network location alone. A public TLS certificate for an internal AI service is not in itself a vulnerability — but it is an indicator that the service has been made reachable via a public CA, which requires verification that authentication and authorisation are enforced at the application layer rather than relying on network isolation.

AI for staff, spend, and security — where the CT finding sits

PromptShield's scanner queries crt.sh, filters AI-specific subdomain patterns, resolves DNS for live services, fingerprints HTTP responses, and probes default paths. The output is a prioritised list of agent infrastructure that warrants authentication review — generated passively, from public data, without touching the target's systems. This is the security layer: find the exposure before an attacker does, with the same tools and the same vantage point.

The spend layer follows from a less obvious implication of the staging environment finding. Staging AI environments — ai-staging, llm-dev — typically carry the same model API access as production, which means any unauthenticated access to a staging inference endpoint incurs real token costs. If there's no finops layer monitoring per-environment spend, anomalous usage from a staging endpoint with inadequate access controls may be invisible until the invoice arrives. PromptShield's cost monitoring treats per-environment spend as a signal — a staging environment consuming production-scale tokens is worth investigating regardless of how the access originated.

The staff layer connects through the registry that the CT log exercise produces. When agent infrastructure is enumerated, authenticated, and brought under management, the same inventory becomes the source of truth for what AI services exist in the organisation — what staff can interact with, what's monitored, and what's blocked. The certificate enumeration exercise is the starting point for an AI agent catalogue that IT can actually maintain.

MITRE mapping

The CT log enumeration technique has direct ATT&CK coverage. The downstream techniques apply where follow-up investigation confirms the underlying conditions.

  • T1596.003 — Search Open Technical Databases: Digital Certificates: querying crt.sh to enumerate subdomains via certificate transparency logs — this mapping applies directly from the CT log query
  • T1046 — Network Service Discovery: DNS resolution and HTTP fingerprinting of discovered subdomains to determine which are live and what they're serving — applies where active probing follows CT enumeration
  • T1190 — Exploit Public-Facing Application: using an unauthenticated /docs or MCP endpoint as an initial access vector — requires the endpoint to be confirmed live and unauthenticated before this mapping applies
  • AML.T0035 — ML Artifact Collection: accessing exposed model serving endpoints or OpenAPI schemas to map model capabilities — applies where an unauthenticated endpoint is confirmed to expose model information
  • AML.T0054 — LLM Prompt Injection via Indirect Means: RAG or agent infrastructure enumeration used to build targeted injection payloads — this mapping describes the attack enabled by the enumeration, not the enumeration itself
  • AML.T0044 — Full ML Model Access: unauthenticated inference endpoint granting direct adversarial model access — applies only where an unauthenticated inference endpoint is confirmed live

What to do about it — three tiers

The CT log check is a passive enumeration that takes minutes to run and produces a prioritised list of services worth reviewing. The remediation work that follows depends on what the follow-up investigation finds.

Immediate actions: Query crt.sh for your domain and filter for AI-specific subdomains. For each subdomain that resolves, verify that it requires authentication before returning any data — a 401 or redirect to an authentication provider on unauthenticated requests is the baseline. For any FastAPI-based service, verify that docs_url=None and redoc_url=None are set in production configuration. For any MCP server with a public certificate, verify that tool enumeration requires authentication.

Short-term (one to two weeks): Migrate internal AI infrastructure to certificates issued by a private CA where public accessibility is not required. A service that should only be reachable from within the VPC has no reason for a certificate from a public CA — and issuing one creates a permanent entry in the CT log. Implement a certificate issuance policy that requires a security review for any new AI-related subdomain receiving a public certificate, and add the AI infrastructure inventory to the quarterly change management audit.

Ongoing: Set up automated CT log monitoring for your domain. crt.sh provides a certificate feed; several open-source tools (certstream, cert-spotter) can alert on new certificate issuance for configured domains in near-real-time. Any new AI-related subdomain appearing in the CT feed that isn't in the approved infrastructure list is a finding worth reviewing before it becomes an incident. NIST SP 800-207's zero-trust principles apply here: treat every new AI service endpoint as untrusted until authentication and authorisation are explicitly verified, regardless of where it sits in the network.

Run the check on your own domain

The crt.sh query takes thirty seconds. The follow-up investigation takes as long as it takes to confirm authentication on each live result. PromptShield's scanner at agentic-response.com automates the full sequence — CT enumeration, DNS resolution, HTTP fingerprinting, and default path probing — and returns a prioritised list of findings. No account required.

All posts