Secured by Shield360 badge: show visitors your AI app is protected

Overview

The Secured by Shield360 badge lets you show the people who use your AI app that Shield360 monitors and protects it. The badge links to a public verification page on Shield360 that says what was checked and when.

The badge is live, not a picture you keep forever:

• It shows Secured by Shield360 · verified <date> only while your app passes every check the badge states, as Shield360 last evaluated them.
• Shield360 evaluates each badge every 15 minutes, and whenever you change it or press Check now.
• When a check fails, when you switch the badge off, or when your organisation no longer has the Security module, the same image shows a neutral Shield360 · verification unavailable, and the verification page says the badge cannot be verified. You get an alert when a badge stops verifying.
• If evaluations stop for any reason, the badge stops verifying an hour after the last one. It never keeps showing “verified” on old evidence.

The badge is part of the Security module.

What the badge checks

You choose which checks a badge states; by default it states all four. The verification page lists the checks that passed.

Check	Passes when
Monitored	Your app (its OpenTelemetry service.name) sent telemetry to Shield360 in the last 24 hours.
Guard on	Your app’s SDK reported, in the last 24 hours, at least one guard running in warn or block mode (the SDK’s guard heartbeat), or a Shield360 guard warned about, redacted or blocked content for your app in the last 7 days (SDK guard reports, or the guard check API called with your app’s name).
Prompt-injection checks on	Your app’s SDK reported its prompt-injection guard on (warn or block) in the last 24 hours, or Shield360 checked your app’s traffic for prompt injection in the last 7 days: a prompt-injection detection from the guard check API or SDK, or a prompt-injection evaluation of one of your app’s spans.
Active Shield360 subscription	Your organisation is on a paid Shield360 plan (not Free, not a trial, not paused or cancelled). On a self-hosted install, the licence verifies and is current.

A check whose evidence Shield360 cannot read at evaluation time (for example during an outage) does not pass.

Note

The guard heartbeat. When your app passes guards to init along with a Shield360 URL and API key, the TypeScript and Python SDKs tell Shield360 once at start and about every 5 minutes which guard kinds run and in which mode (off, warn or block), and whether prompt-injection checks are on. It carries no text, host or user, and it is never counted as a guard decision. So Guard on and Prompt-injection checks on pass for an app whose guards had nothing to stop, as long as it is running. Use an SDK version with the heartbeat; it is on by default (turn it off with guardHeartbeat: false / guard_heartbeat=False or SHIELD360_GUARD_HEARTBEAT=false). A guard in allow mode counts as off. Apps that call only the guard check API pass on the decisions it records.

What the badge does not claim

The badge states what Shield360 observed about your app’s AI traffic. It is not:

• a certification, an audit or a penetration test;
• a statement that your app, site or infrastructure is free of vulnerabilities;
• a statement that every request passed through a guard. Shield360 sees the calls your app reports; calls made outside the SDK or the guard check API are not covered;
• a statement about anything other than the app it was issued for.

The verification page says so in plain words.

Set up a badge

1. Open Applications & agents, choose your app and open its Security tab.
2. Under Secured by Shield360 badge, select Set up a badge.
3. Choose the checks the badge states, and optionally:
   • a name shown publicly (otherwise the app’s service name is shown);
   • whether the verification page shows your organisation’s name (off by default);
   • the sites the badge may appear on (see Copied badges).
4. Switch Badge on. Shield360 checks the app straight away and shows each check’s result.
5. Copy one of the embed snippets into your site.

Creating and changing badges needs a role that may manage policies (Owner, Admin or Security). Anyone who can view Data protection can see a badge’s settings and status.

Embed code

Two snippets are offered. Neither runs script on your page.

The image badge, a link around an SVG image:

<a href="https://app.shield360.ai/verify/badge/<badge id>" target="_blank" rel="noopener"><img src="https://app.shield360.ai/badge/<badge id>.svg" alt="Secured by Shield360" height="28"></a>

A text link, for pages that load no third-party images:

<a href="https://app.shield360.ai/verify/badge/<badge id>" target="_blank" rel="noopener">Secured by Shield360: verify</a>

The badge id is random and is not your app, project or organisation id.

Copied badges

Because the image and the verification page are served by Shield360, a badge copied onto another site only ever shows the current state of your app, and it stops verifying when you switch it off. To limit where it appears:

• Register your sites. List up to 10 host names; subdomains are included. The verification page lists them, so a visitor can see whether the badge is on the right site. When a visitor’s browser says which page is showing the image (the Origin or Referer header), a badge shown on any other site displays “verification unavailable”.
• Give the badge a new address. New badge address replaces the badge id. Every copy of the old embed code, wherever it was pasted, shows “verification unavailable” from then on. Paste the new code on your own site.

Caution

The site check is best effort. A page can stop its visitors’ browsers from sending a Referer (for example with Referrer-Policy: no-referrer); the badge is then shown, because the site cannot be told. Tools that are not browsers can send any header. The registered-sites list on the verification page is the check a visitor can always make.

Verification page and public data

https://app.shield360.ai/verify/badge/<badge id> needs no account. While the badge verifies, it shows only:

• the app’s public name, and your organisation’s name if you chose to show it;
• the checks that passed;
• when they were last verified;
• the sites you registered.

It never shows your environment, project, service name (when you set a public name), evidence counts, people or computers. A badge that is switched off, failing, removed, or unknown shows the same “verification unavailable” message, so the page reveals nothing about why.

Verify a badge offline

Third parties (marketplaces, procurement tools, security reviewers) can fetch a signed statement and check it without trusting the page:

curl https://app.shield360.ai/api/badges/<badge id>

While the badge verifies, the answer carries the same public fields as the page, plus:

Field	Meaning
statement	A compact JWS signed with EdDSA (Ed25519), header typ shield360-badge+jwt and the signing key’s kid.
kid	The key id. Fetch the public key from /api/badges/keys?kid=<kid> (a JWK set with one OKP Ed25519 key). Keys are never listed.
expiresAt	When the statement expires: at most one hour after it was issued, and never later than one hour after the evaluation it rests on.

The statement’s claims are iss (the Shield360 deployment), sub (badge:<badge id>), iat, exp, status (verified), app, organisation (only when shown), checks, verified_at, domains and verify_url. Reject a statement whose signature does not verify with the key for its kid, whose exp has passed, or whose sub is not the badge you expect. A copy kept elsewhere stops verifying within the hour.

A badge that does not verify answers { "data": { "status": "unavailable" } }, with no statement.

The statement is signed with your environment’s attestation key, the same key Shield360 uses for agent passports and agent mandates.

Revocation and alerts

A badge is withdrawn at the evaluation that finds a stated check failing, or as soon as you switch it off or remove it. Images and statements may be cached by browsers and proxies for at most 5 minutes (and never past the evaluation going stale), so a change shows on your site within minutes.

When a badge that was verifying stops, Shield360:

• records it in the audit log (app_badge.revoked, with the failing checks), and records app_badge.restored when it verifies again;
• raises a badge.revoked alert to your organisation, once per failing run. Route it to Slack, Teams, email or a webhook with an alert rule.

Turning a badge on or off, changing it, giving it a new address and removing it are recorded in the audit log like any other change.

Limits

The public endpoints are rate limited per visitor address. Badge images and statements are answered from each badge’s last evaluation; visitors never cause Shield360 to read your telemetry.