presentsUNAIVERSE
The UN AI timeline

    Learn AI /AI Security /Secrets management

    Secrets management

    Also called: API key handling, credentials.

    Detail

    In five seconds

    What it is

    The practice of storing and using passwords, tokens and keys safely so people and software can reach services without exposing those credentials.

    In plain words

    Keep passwords, API keys and tokens in a protected place, let only approved people or software retrieve them, and replace them if they may have leaked.

    An everyday example

    In a municipal office, different staff sometimes need keys for the archive room, the vehicle gate, and the supply store. The keys are not left on desks or copied into notebooks. They are kept in a locked cabinet, and each person signs out only the key they are authorised to use for a limited time. If one key goes missing, the office changes that lock and updates who can borrow the replacement.

    Where the story stops working

    Physical keys and digital credentials behave differently. A stolen physical key usually opens one lock, but a leaked digital credential can be copied perfectly, shared instantly across borders, and used many times without the owner noticing. Also, software can retrieve secrets automatically at high speed, which is not like a person visiting a cabinet.

    Remember thisCredentials belong in controlled secret stores, not in code, prompts or shared files. Give each workload only the access it needs, use short-lived credentials where possible, and rotate or revoke them centrally.

    Understand it

    Understand it

    Why it matters

    For a non-specialist, this matters because many AI and cloud tools depend on credentials that quietly grant real power: spending on paid services, reading data, sending data elsewhere, or acting under your organisation's name. If a secret leaks, the damage may look ordinary at first: unexpected charges, missing quotas, suspicious activity, or data leaving a system. Good secrets management reduces those risks and makes incidents easier to contain. It also supports accountability, because teams can see which application used which credential and replace it without shutting down everything. In practical terms, it is a basic control for safe AI use, procurement, system design and staff behaviour.

    How secrets should move through a system

    After viewing, the reader should be able to explain why credentials belong in a protected store rather than inside code, prompts or documents.

    1. 01

      Store

      Place the credential in an approved secret store, not in code, spreadsheets, tickets or prompts.

      Draw a vault icon at left labelled 'Secret store'. Below it, add three small red crossed-out icons labelled 'code', 'shared doc' and 'chat prompt'.

    2. 02

      Verify requester

      The user or application first proves its identity before asking for the credential.

      Show a person icon and an app icon feeding into a checkpoint labelled 'identity check'.

    3. 03

      Give limited access

      The store returns only the needed secret, often for a limited time and for one specific purpose.

      Draw a narrow arrow from the vault to the approved app with a small tag reading 'specific' and 'temporary'.

    4. 04

      Use service

      The app uses the credential to call the external or internal service, such as an AI model API or database.

      Show the app sending a request to a service box labelled 'AI service / database' using the credential.

    5. 05

      Rotate and revoke

      If the credential expires, staff leave, or exposure is suspected, replace it and stop the old one from working.

      At the far right, draw a circular arrow around a key icon and a stop symbol over an old key.

    A left-to-right step diagram with two lanes: person/app actions on top and system handling below. It shows a secret being stored once, requested by an approved app, delivered briefly, used to call a service, then rotated. A red warning marker appears beside unsafe places such as source code, chat prompts and shared files.

    On hover or tap, each unsafe location highlights examples of accidental exposure such as code repositories, screenshots, logs and copied prompts.

    Describe this without the diagram

    This diagram explains a five-step process for handling credentials safely. Step 1: store passwords, API keys or tokens in a protected secret store and not in code, shared documents or chat prompts. Step 2: before any secret is released, the person or application must prove its identity. Step 3: the store gives only the needed credential, often temporarily and for one task. Step 4: the application uses that credential to reach an AI service or database. Step 5: the credential is rotated or revoked if it expires, staff roles change, or exposure is suspected. The key message is that secrets should move through controlled systems, not be copied into everyday places.

    With reduced motion: A static five-panel diagram shows the same sequence without animation: secret store, identity check, limited release, service use, and rotation or revocation, plus crossed-out examples of unsafe storage.

    Many digital services need a secret before they will respond. That secret might be a password, an API key, or a token. A token is a credential that may represent identity or granted access and may expire. Secrets management means keeping those credentials in approved places, giving access only to the right users or software, and replacing them when needed.

    What goes in are the credentials and the rules around them: who may use them, for which service, and for how long. Instead of hard-coding a key into an app, a document, or a chat prompt, an organisation stores it in a protected system such as a password manager, a secret vault, or a cloud key store.

    What happens next is controlled retrieval. The person or application asks for the secret, proves its identity, and receives only the specific credential it is allowed to use. Good systems also record access, rotate secrets on a schedule or after an incident, and revoke them when staff leave or a key may have leaked.

    What comes out is not just access to a service. The result is lower risk. If a key is exposed in code, email, screenshots, logs, or an unapproved AI tool, others may use it to spend money, extract data, or act as your system. Secrets management is often confused with access control. Access control decides who may do what; secrets management focuses on protecting the credentials used to get that access in the first place.

    How “A building office with a locked key cabinet” maps onto the real thing

    In the storyIn the AI system
    Locked key cabinetSecret vault or approved store for credentials
    Staff signing out a specific keyA user or application retrieving only the secret it is permitted to use
    Limited borrowing timeTemporary tokens or short-lived credentials
    Changing a lock after a missing keyRotating and revoking exposed credentials

    A worked example

    Before the quarterly report workflow is run, the security analyst replaces a long-lived service credential embedded in its configuration with controlled retrieval from an approved secret vault.

    Starting from: Access requirement: the reporting script may call one approved summarisation service, using a credential unavailable to users and other applications.

    1. Create a dedicated workload identity for the reporting script and grant it only the permission needed to call the summarisation service.
    2. Store the credential in the approved secret vault rather than in source code, configuration files or notebooks.
    3. Configure the script to retrieve a short-lived credential at runtime, without printing it to logs or exposing it in error messages.
    4. Test the workflow and review the audit log to confirm that only the assigned workload identity retrieved and used the credential.
    5. Revoke the embedded credential, check repository history and shared copies for exposure, then use automated rotation for its replacement.

    Result: The workflow can be circulated, maintained and rerun without distributing the credential. Access can be traced, rotated or revoked centrally, including when a credential is exposed or the workflow is retired.

    In a United Nations workplace

    In a liaison office, a security analyst reviews the workflow used to compile the quarterly progress report for a donor. A script calls an approved language-model service to summarise cleared monitoring updates, but its access token has been pasted into a configuration file that would be uploaded to the shared repository.

    The analyst moves the credential to the approved secret vault and gives the reporting script identity-based, least-privilege access. The script retrieves a short-lived token when it runs, while access and rotation are logged. The file can then be shared for clearance without also circulating the means to call the service.

    Before you try thisThe exposed token must be revoked, not merely deleted from the latest version of the file, because it may remain in repository history, logs or earlier copies. Credentials must never be placed in prompts, email, collaboration tools or unapproved systems. Only material authorised for the approved model service may be processed.

    Where you may hear it

    • A security review before a reporting script is uploaded to the repository
    • An ICT governance board discussion on connecting an AI service
    • A vendor demo during a procurement meeting
    • An incident response call after a token appears in a log
    • A developer onboarding session before access to the secret vault is granted

    Avoid confusion

    Avoid confusion

    Often confused with

    Common misconceptions

    • 'If the code repository is private, putting API keys in the code is fine.'

      Private repositories still get copied, forked, backed up, screenshotted and shared with contractors or former staff. Keys may also appear in logs or error messages. Storing them separately means you can limit access and replace them without editing every copy of the code.

    • 'Secrets management is only for programmers.'

      Non-technical staff also handle credentials in spreadsheets, shared drives, screenshots, browser bookmarks and prompts to AI assistants. A leak can happen through routine office behaviour, not only through software development.

    • 'A long random key is safe wherever I paste it because people cannot guess it.'

      Randomness helps against guessing, but not against exposure. If the key is pasted into email, chat, a ticket, or an unapproved AI service, someone or some system may still store and reuse it.

    • 'This is the same as access control.'

      They are related but different. Access control defines which users or systems should have permissions. Secrets management protects the credentials used to obtain those permissions and manages their storage, delivery, rotation and revocation.

    Quick check

    Which practice best shows good secrets management for an AI application?

    Go deeper

    Go deeper

    The simple version

    Keep passwords, API keys and tokens in a protected place, let only approved people or software retrieve them, and replace them if they may have leaked.

    The technical version

    Secrets management covers the secure storage, distribution, use, rotation and revocation of credentials such as passwords, API keys, private keys and tokens. Common controls include encrypted secret vaults, identity-based retrieval, least-privilege access, short-lived credentials, audit logging, environment-variable injection, and automated rotation. The goal is to avoid embedding secrets in source code, configuration files, prompts, notebooks, client-side apps, logs or collaboration tools. In AI systems, this matters because model providers, vector databases, orchestration tools and plug-ins often require credentials; exposure can enable unauthorised API calls, data access, quota abuse or downstream compromise. It is adjacent to, but distinct from, authentication and authorisation: those govern how identities and permissions are established, while secrets management protects the material used within that process.

    Reviewed external resources

    Where this came from

    Drafted with a language model through an offline pipeline, checked against this site's schema, and every external link above fetched to see whether it answers. Treat it as a starting point and check anything that matters against the primary sources. How this site is built and what that means.

    The one thing to remember

    Credentials belong in controlled secret stores, not in code, prompts or shared files. Give each workload only the access it needs, use short-lived credentials where possible, and rotate or revoke them centrally.