# Who has the project keys? Identities and secrets for applications and agents

> Identities for applications and agents, protected secrets, and temporary access: practical steps for a digital project’s infrastructure.

Source: https://i8.ro/en/blog/who-holds-the-project-keys-identities-and-secrets-for-applications-and-agents

**Series II: From infrastructure to agentic projects in production. Episode 04 of 20.**

In [the previous episode](https://i8.ro/en/blog/virtual-routers-and-separate-networks-limiting-incident-impact), we separated the networks of the fictional B2B portal for requests and documents. A firewall rule can allow the API to reach the database, but it doesn’t prove the process requesting access is truly the authorized API. The main decision in this episode is to give each person, service, and automated process a distinct identity, then prefer temporary credentials over shared, permanent keys wherever integration allows.

## Identity is not the secret

A **workload identity** represents a running program, such as the API, a delivery job, or an agent. Here, workload means a unit of execution, not a human user. **Authentication** verifies identity, while **authorization** determines what that identity is allowed to do. A service authenticating correctly doesn’t automatically grant it access to all data.

A **secret** is a value that must remain confidential, such as a password, an API key, or a private key. A **temporary token** is a credential valid for a limited time. Expiration reduces the window during which a stolen copy can be used, but doesn’t prevent abuse while valid, nor does it fix overly broad authorization.

Therefore, we don’t call all these elements “keys.” First, we identify the actor, then the method proving their identity, the permitted resource, and access duration.

## Four different actors in the portal

**Hypothetical scenario:** The portal has an API, a process handling documents, a CI/CD pipeline deploying versions, and an integrated AI agent that suggests request classification. The team also uses development AI agents for code and tests, separately.

Human operators log in using individual accounts, ideally with multifactor authentication and no shared admin account. The API and the document process receive different service identities, as they perform different tasks. The CI/CD job uses an identity valid for the approved run and environment. The integrated agent triggers controlled application functions—not database access with the API password. The development agent operates in the test environment and the repository, with no direct path to production.

This separation complements the [general rules concerning permissions, approvals, and audit](https://i8.ro/en/blog/permissions-approvals-and-audit-the-rules-for-a-trustworthy-ai-agent). Here we’re interested in implementing identity in infrastructure, and the credential lifecycle.

## Where do we store the secrets that remain necessary

Some systems don’t support federated identities or dynamic credentials. For them, a secrets manager can store values encrypted, control who reads them, and log access. Choose the product after inventory, not before. A `.env` file can be convenient locally, but it’s not a vault just because it’s excluded from Git. It can wind up in a backup, a container image, a shared folder, or on a tool’s screen.

Secrets don’t go into code, prompts, examples, tickets, or logs. If a development agent needs to run tests, we provide synthetic data and credentials for the test environment, injected only at runtime. We don’t ask a model to “remember” a key. If the integrated agent must use an external provider, its process reads the secret via a controlled mechanism; the secret is not included in instructions sent to the model.

Academic research on public repositories has shown that key and secret leaks aren’t marginal cases. Automated scanning can detect some errors, but it doesn’t make accidental publication safe. A key that lands in history is considered compromised: we revoke or rotate it at the provider, investigate usage, and only then clean up copies where possible.

## When OIDC and SPIFFE help

**OpenID Connect**, abbreviated OIDC, allows a trusted party to verify claims about an identity. In GitHub Actions, for example, a job can receive an OIDC token, and a cloud provider can exchange it for a short-lived access credential. As a result, the permanent cloud key no longer needs to be copied into the repository. Still, the trust policy should be tightened by repository, environment, branch, and audience, according to the provider’s capabilities. A token issued to any job is not an improvement if the cloud role remains overly broad.

**SPIFFE** is a set of standards for workload identity in dynamic, heterogeneous environments. A service can receive a verifiable identity document, called SVID, used for authentication between services. SPIFFE is not a drop-in replacement for OIDC or all passwords. Moreover, its documentation assumes workloads are isolated well enough that one can’t steal another’s credentials; enforcing that isolation is outside the standard. Segmentation from the previous episode remains important.

For SMEs, the practical rule is to first use the native mechanism provided by the platform already in use. OIDC can eliminate the permanent key from cloud deployments. A workload identity issued by the orchestrator can separate the API from the document process. SPIFFE is worth evaluating when the project spans platforms and has sufficient operational complexity. Introducing an identity infrastructure more sophisticated than the managed system may shift risk, not eliminate it.

## The registry that makes access verifiable

Before configuration, we complete a simple registry. The table’s values are suggestions for the fictional scenario, not a certified configuration.

| Identity | Resource and purpose | Credential | Duration / revocation | Owner |
| --- | --- | --- | --- | --- |
| Production API | Database, application operations | Service identity or dedicated secret | Temporary or scheduled rotation | Application owner |
| Delivery job | Production environment, deploy only | OIDC and temporary cloud token | Single run; revoking the trust relationship | DevOps |
| Integrated agent | Classification API and model service | Separate identity and controlled secret | Session or documented rotation | Product owner |
| Development agent | Repository and testing environment | Limited technical account | Per task; revocation at completion | Technical lead |

For each row, we check who approves access, where it appears in logs, which dependency issues it, and how we revoke it. We test both an allowed operation and one that should be denied. Rotation is tested before an incident: the service must pick up the new credential without the old value remaining active and uncontrolled. We keep the recovery procedure for secret manager unavailability separate, protected, and accessible only to designated personnel.

The result is a registry of identities and secrets, with owner, purpose, duration, and revocation procedure. It shows where permanent credentials still exist and provides a plan for their reduction. 

In the next episode, we’ll translate some of these rules into infrastructure as code, so that environments can be rebuilt and validated.

## Sources

- [SPIFFE, *Overview* and *Concepts*](https://spiffe.io/docs/latest/spiffe-about/overview/), official documentation on workload identity and SVID, consulted on October 6, 2026.
- [GitHub Docs, *OpenID Connect*](https://docs.github.com/en/actions/concepts/security/openid-connect), about exchanging a job’s identity for a temporary cloud token.
- [OWASP Cheat Sheet Series, *Secrets Management*](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html), on storage, duration, rotation, logging, and incident response.
- [Meli, McNiece and Reaves, *How Bad Can It Git?*, NDSS 2019](https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/), an academic study on secret leakage in public repositories.

## Next step

Want to reduce permanent access and keys scattered throughout projects? [Talk to i8 about an identity registry and a migration plan](https://i8.ro/en/contact).