A secret manager controls how an application obtains a credential. An API proxy can let the application perform an operation without obtaining the provider credential at all.
The distinction is whether the workload needs the credential or permission to perform an operation.
What a secret manager does
A secret manager stores sensitive values such as API keys, database passwords, signing secrets and certificates. It controls which people and workloads may retrieve them.
The application authenticates to the secret manager using a workload identity, cloud role, access token or another bootstrap mechanism. The secret manager checks its policy and returns the requested value. The application then uses that value to call Stripe, AWS, Twilio or another provider directly.
This replaces manually copied files with a managed process. Depending on the product and configuration, it can provide:
- encrypted storage;
- access policies;
- separate secrets for different applications and environments;
- versioning and rotation;
- records of secret retrieval;
- central removal of access;
- injection into deployment or runtime environments.
The authorised workload ultimately receives the credential, perhaps in memory, its process environment or a temporary file. The secret manager controls retrieval, but the application remains trusted with it.
Does putting an API key in .env make it secure?
What an API proxy or relay does
The application sends an authenticated operation or provider-native request. The intermediary checks permission, applies the provider credential, calls the provider and returns the result.
The application may never receive the provider credential.
For example, an application can submit email to an SES relay. The relay holds the AWS credentials, calls SES and returns the message ID. The application can send email without receiving the AWS key.
The application needs an identity for the proxy. This separates authority to request an operation from possession of the provider credential.
Your application does not necessarily need your API key
The core difference
A secret manager answers:
Is this workload allowed to retrieve this secret?
An API proxy answers:
Is this workload allowed to perform this operation?
That distinction changes the trust boundary.
After retrieval, the application sits inside the provider credential’s trust boundary. A Stripe secret key lets it attempt whatever that key permits at Stripe.
With a proxy, the application sits outside the provider credential boundary. It has whatever authority the proxy gives its application identity. A narrowly designed proxy might allow Stripe PaymentIntent creation but not refunds or customer deletion. A broader proxy might allow most Stripe requests but still keep the actual Stripe key unavailable to the application.
Neither boundary is automatically correct. It should match the job the application needs to do.
Side-by-side comparison
| Area | Secret manager | API proxy or relay |
|---|---|---|
| Primary job | Store secrets and control retrieval | Authorise and perform provider operations |
| Does the application receive the provider credential? | Usually yes | Not necessarily |
| Provider flexibility | High; the application can use the provider API directly | Limited by the proxy’s supported requests and policies |
| Provider coverage | Can store almost any secret value | Requires an implemented provider or suitable generic relay |
| Latency | Direct provider call after retrieval | Adds an intermediary network hop |
| Main runtime dependencies | Secret retrieval path and provider | Proxy and provider |
| Typical failure modes | Retrieval failure, stale secret, permission error, provider failure | Proxy failure, proxy permission error, provider failure |
| Auditability | Strong for secret access; provider records operations | Can record application-level operations without revealing the key |
| Rotation | New value must reach or be reloaded by authorised workloads | Provider key can change behind the proxy without app changes |
| Migration | Usually change how configuration is loaded | Change the provider request path and application authentication |
| Operational work | Policies, identities, rotation and secret lifecycle | Credentials plus request validation, capacity, retries and provider handling |
| Vendor dependency | Secret storage and retrieval mechanism | Runtime request path and supported provider behaviour |
Credential exposure
With a secret manager, the credential is exposed to the application by design. “Exposed” does not mean publicly disclosed. It means the process is authorised to obtain and use the value.
Application code, libraries running in the same process and sufficiently privileged diagnostic tooling may therefore be able to read it. Careless configuration dumps or request logging can copy it into places it does not belong.
An API proxy keeps the provider credential out of the application. A compromised application might still abuse its proxy permissions, but it may be unable to obtain the provider credential or use it outside the proxy’s permitted path.
Replacing a restricted provider key with a proxy identity allowing every operation may not reduce authority much. A proxy matters when it creates a meaningful boundary.
Flexibility and provider coverage
Secret managers are provider-agnostic. If a value can be stored as a secret, the manager can usually hold it. The application remains free to use every API operation, SDK feature or protocol supported by the provider.
That makes secret managers the better general-purpose tool. They do not need a custom integration for every API.
An API proxy has to understand or pass through the operation. A relay may send email without supporting every SES administrative action. A broader proxy still needs rules for methods, endpoints, payloads, versions and errors.
This constraint can be the point. It can also become a limitation when the provider changes rapidly or the application needs unusual features.
Latency and failure modes
After retrieving a secret, the application normally calls the provider directly:
Application → Provider
A proxy adds another runtime step:
Application → Proxy → Provider
That adds latency and another service that can fail. If the proxy is unavailable, the operation fails even when the provider is healthy. It needs suitable timeouts, monitoring and capacity.
The extra hop is often insignificant for transactional email, payment setup or short control requests. It may be a poor trade for streaming AI output, high-volume low-latency calls or large file transfers.
A proxy can sometimes avoid carrying the main workload. For S3, it can create a short-lived presigned URL and let the client transfer the file directly to S3. The credential stays at the proxy without turning the proxy into a file-transfer bottleneck.
Vendor dependency and migration
Both models create dependency, but in different places.
A secret manager becomes part of credential storage and retrieval. Migrating generally means exporting secrets, rebuilding access policies and changing how workloads authenticate or load configuration. Provider calls can remain unchanged.
An API proxy becomes part of the application’s live provider path. Migrating away may require changing endpoints, request signing, error handling and possibly request formats. If the proxy preserves the provider’s native payload closely, migration is easier than if it replaces the provider API with a proprietary abstraction.
A proxy can reduce repeated provider plumbing across applications, but couples those applications to the proxy instead.
Auditability
A secret manager can tell you that application A retrieved version 7 of a Stripe key at a certain time. It may not know what the application did with that key afterward. Provider-side logs may supply the rest.
A proxy sits in the operation path, so it can record that application A requested a particular Stripe endpoint or submitted an SES email. This gives application-level operation records even when several applications ultimately use the same provider account.
The proxy must avoid logging authorisation headers, credentials and sensitive payload fields. More logging is not automatically better.
Operational overhead
A secret manager requires identities, policies, secret versions, rotation procedures and reliable retrieval. In an established cloud environment, much of this may fit naturally into infrastructure already in place.
A proxy adds a reliable API service. It must authenticate applications, authorise operations, handle provider errors, track changes and remain available under load. Some operations also need retries, webhook handling or temporary storage.
It can reduce total work when several applications would otherwise rebuild the same integration. For one application with a well-scoped key, direct access may be simpler.
When the workload needs the credential locally
A secret manager remains the right tool when the workload genuinely needs direct possession of the credential.
Examples include:
- a service using a broad or rapidly changing provider API;
- an application that relies heavily on the provider’s SDK;
- streaming requests where an intermediary adds unwanted latency;
- local signing or decryption that cannot be delegated;
- command-line or batch jobs designed to communicate directly with the provider;
- workloads using short-lived credentials issued specifically for them.
In these cases, forcing every request through a proxy may add complexity without producing a useful permission boundary. Retrieve the credential through a secret manager, restrict it at the provider where possible, and let the workload use it.
Where should application secrets live?
When the application only needs an operation
A proxy is worth considering when the application needs a narrow, repeatable capability rather than general access to the provider account.
Sending transactional email is a good example. The application needs to submit a message. It may not need an AWS credential capable of direct SES access.
The same can apply to verifying an anti-bot response, creating a presigned upload, sending an SMS or performing selected payment operations. A proxy can give each application its own identity, enforce the relevant capability and keep the provider credential elsewhere.
This is especially relevant when development and production environments use AI coding tools. Keeping production provider credentials outside the workspace limits what those tools can ever retrieve, although the application’s proxy identity must still be handled properly.
AI coding agents and API credentials
Some systems can use both models
The two approaches do not have to be chosen once for an entire application.
An application might retrieve an AI provider key from a secret manager because it needs direct streaming access, while sending transactional email through an SES relay. It might retrieve a database password locally but request S3 presigned URLs through a proxy.
Gateman supports both patterns for different cases. For example, its email.send capability accepts authenticated POST /send/ses requests with the application’s message payload and required environment; the application needs the email.send scope, while Gateman keeps the configured provider credential and captures staging/development messages locally. The official PHP, Node.js, Python and Go clients can inject the environment for the same application code across environments.
For supported provider operations, an application authenticates to Gateman and submits an allowed request. Gateman applies the stored provider credential and communicates with the provider. The application does not receive that underlying credential. It still has Gateman application identity and signing material to protect.
For generic secrets and providers better called directly, an authorised application can retrieve the approved secret and use it itself. In that path, Gateman is distributing the credential rather than proxying the operation.
This is not a claim that a proxy replaces a general secret manager. The question is which boundary fits each credential and operation.
Choose based on what the workload needs
Use a secret manager when the workload needs the credential. Use an API proxy when the workload needs an operation and there is value in keeping the provider credential outside it.
Sometimes the direct model is cleaner. Sometimes the proxy boundary materially limits authority, simplifies rotation or removes production provider keys from application environments. Many systems reasonably use both.
The useful question is not which category of product is better. It is whether this workload needs the secret itself—or only permission to do something with it.