Shield360 API keys
Overview
Section titled “Overview”Applications, the Shield360 SDKs, CI jobs and scripts call Shield360 with an API key. Examples are fetching a prompt from Prompt Hub, reading a secret from the Vault, evaluating a rule or running an agent test suite. Settings → Developer → Shield360 API keys (/settings/api-keys) is where those keys are created, listed and revoked.
Each key is:
- bound to one environment: the project database (database configuration) that was selected in the header when the key was created;
- acting for the person who created it: it can do what its creator can do in that environment’s organisation and project, and nothing more;
- shown once: Shield360 keeps only a hash of the key, so it cannot show the key again.
Who can manage keys
Section titled “Who can manage keys”| Permission | Allows | Held by |
|---|---|---|
api_key.read (View API keys) | See which keys exist, who created them and when they were last used | Owners and administrators |
api_key.create (Create API keys) | Create keys | Owners and administrators |
api_key.delete (Revoke API keys) | Revoke keys | Owners and administrators |
An external Auditor cannot create a key, whatever their permissions: Auditors cannot create API keys. Only members of this organisation can.
What a key can do
Section titled “What a key can do”A request made with a key acts as the key’s creator, in the key’s environment:
- The creator’s role in the organisation, and their role in the key’s project, decide what the key may do. The same server checks apply as for a signed-in person.
- If the creator’s role changes, the key’s access changes with it.
- If the creator leaves the organisation, their keys stop working. When a member is removed, their keys are revoked and the audit log records how many.
- By default a request reads and writes the key’s own environment. An SDK endpoint may name another environment of the same project instead. A database configuration outside the key’s project is refused with
403. - Some pages need a signed-in person and refuse keys. For example, Live traffic reads every project you can see, so it needs a session.
Every change made with a key is in the audit log, with the actor shown as API key "<name>".
Send the key as a bearer token:
curl https://<your-shield360-host>/api/prompt/get-compiled \ -H "Authorization: Bearer $SHIELD360_API_KEY" \ -H "Content-Type: application/json" \ -d '{"name": "support-reply"}'See the API reference for the endpoints and their request headers.
Create a key
Section titled “Create a key”Choose the project and environment the key is for. The page shows New keys send data to:, followed by the database configuration’s name, its database and its environment. If the project has more than one database for that environment, it warns you to check that the one shown is the one you mean. If no database is selected, it warns that keys created now will not work.
Give the key a Name of at least three characters that says where it is used, such as ci-agent-tests or support-bot-prod. Then select Create.
The key starts with shield360-. It is copied to your clipboard and shown in the dialog with a Copy button. Store it in your secret manager now. After you close the dialog, Shield360 keeps only a hash.
The key list
Section titled “The key list”The list shows the keys of the environment selected in the header.
| Column | Shows |
|---|---|
| Name | The name given when it was created |
| API Key | A label such as shield360-… #k3x9q2ab. The part after # is the end of the key’s record id, not any character of the key itself |
| Created By | Who created it, and so whose access it uses |
| Created At | When it was created |
| Last Used | When it was last used, updated at most every five minutes, or Never used |
Revoke a key
Section titled “Revoke a key”Select the bin icon on the key’s row and confirm. The key stops working on its next request. Applications still using it will start to fail, so replace it first.
Rotate keys regularly and after team changes, and revoke any key that is unused or may have been exposed. Creating and revoking keys are both recorded in the audit log.