Site Audit
Runs DNS, TLS, HTTP, redirect, and security-header checks against a public site. Give your agent one structured report with the most useful findings.
site_audit5 sats per call. LiveAuth authenticates and meters the request; the result goes directly back to your agent. The proof-of-work session flow requires no agent account, subscription, or human payment step.
Example input
{
"target": "https://example.com"
}Accepts HTTP/HTTPS URLs or bare hostnames, which default to HTTPS. Public sites only.
Example output
{
"hostname": "example.com",
"score": 95,
"issues": [
{
"severity": "warning",
"code": "missing_csp",
"message": "content-security-policy is absent; consider this recommended protection where appropriate."
}
]
}Shortened and illustrative. The full response also contains DNS, TLS, HTTP, and security-header details.
What is checked
- DNS: A, AAAA, CNAME, MX, and nameserver records.
- TLS: certificate identity, validity, negotiated protocol, and certificate chain.
- HTTP: response status, headers, timing, and redirect chain.
- HTTPS usage: whether the response and redirect path use encryption.
- Security headers: HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy.
- Findings: consistent issue codes and severity levels that your agent can prioritize.
- Informational score: a concise 0–100 summary.
How to read the score
The score is an informational heuristic, not a formal security certification. It starts at 100, deducts 25 per critical finding and 5 per warning, and stays between 0 and 100. Informational findings deduct nothing. Header recommendations depend on the site's purpose; presence alone does not prove a correct policy.
Useful results when a check fails
Available checks can still be returned when one inspection area fails. For example, a TLS failure can appear as a finding alongside available DNS and HTTP results. An unreachable or disallowed starting destination may prevent an audit. TLS checks the original host; HTTP follows redirects to the final response.
Authentication, billing, and retries
Authentication happens first. LiveAuth then meters an accepted execution at 5 sats, and InvokeWorks returns the result with billing metadata and a receipt. An execution that fails after charging remains billable.
Retry the same call with the same idempotency key to avoid a duplicate charge. The audit may run again; retry-safe billing does not mean the result is cached. Use a new key for each new logical call.