# Security overview

Gateman is designed to make supported provider integrations easier to secure and manage. Its practical benefits are:

- fewer provider credentials distributed across applications, deployments, CI/CD systems, local machines, and integrations;
- less routine sharing of AWS, Stripe, and other provider credentials with coding agents or third parties; and
- clearer organization of applications, provider configuration, capabilities, and team access.

This reduces credential sprawl and makes access decisions easier to inspect. It does not make applications credential-free or eliminate the need for careful application and provider security.

## Keep provider credentials out of application deployments

Without Gateman, the same provider credential may be copied into source-adjacent configuration, deployment environments, CI/CD secrets, local development machines, and multiple application instances. For supported capabilities, Gateman can keep the underlying provider credentials in its protected storage and use them when an authenticated application requests an operation. The application carries Gateman signing credentials instead of the provider credential itself.

This is a reduction in distribution, not a promise that credentials are never exposed. Applications still need sensitive Gateman signing material. Authorized credential-retrieval capabilities intentionally return protected values, and unsupported integrations may still require direct provider credentials. See the [capability references](https://docs.getgateman.com/capabilities/email.send/) for the boundary of each supported operation.

## AI-assisted development without sharing provider secrets

Gateman's [bootstrap context](https://docs.getgateman.com/bootstrap-context/), capability references, and [Official clients](https://docs.getgateman.com/using-gateman-with-coding-agents/) give a coding agent the information needed to implement supported integrations without routinely receiving the underlying AWS, Stripe, or other provider credentials. This can keep provider access out of ordinary implementation conversations and local agent environments.

Gateman application signing material remains sensitive, and developers control what they expose to an agent. Gateman does not prevent a developer from voluntarily sharing a secret, and an agent may encounter a value if a developer supplies it or authorizes a credential-retrieval operation. An agent does not receive a Gateman account-management API through which it can independently administer accounts or enable arbitrary capabilities.

## Keep applications and access organized

Gateman brings application configuration, provider integrations, enabled capabilities, stored credentials, and team access into one account-level view. That helps a team understand which applications can use which services, avoid unnecessary credential duplication, disable application access when required, and change or revoke console access without hunting through unrelated deployment systems.

Organizational clarity is a security benefit: it reduces forgotten configurations and makes the relationship between an application, its allowed operations, and its provider configuration easier to review. Provider permissions and application security remain the customer's responsibility.

## How Gateman protects access

Applications authenticate requests with either Ed25519 or HMAC-SHA256 signing. Signed requests cover relevant request metadata and the request body, and Gateman checks timestamp freshness; the current freshness window is five minutes. This authenticates the calling application and protects request integrity. Ordinary signed requests are not all strictly single-use, so capability-specific idempotency and single-use credential-retrieval claims provide separate protections where applicable.

Gateman authorizes the requested capability and applies the relevant application controls, including active status, configured capability scope, source-IP restrictions where configured, operation-specific checks, rate limits, and concurrency limits. A Gateman capability does not grant unrestricted provider access: provider-native IAM, API-token permissions, account context, and provider authorization remain authoritative.

See [Authentication](https://docs.getgateman.com/authentication/), [Contract v1](https://docs.getgateman.com/contract-v1/), [Idempotency](https://docs.getgateman.com/idempotency/), and [Rate limits and concurrency](https://docs.getgateman.com/rate-limits-and-concurrency/) for the detailed contracts.

## Credential protection and application isolation

Provider credentials are encrypted at rest in the reviewed Gateman credential stores using KMS-backed protection and application/provider-specific encryption contexts. Gateman decrypts credentials when needed for an authorized operation; it is therefore a trusted service that can access the credentials it operates with.

Account- and application-scoped repositories, authorization checks, identifiers, foreign-key relationships, and relevant tests separate customer data and associated provider configuration. These are implemented controls, not a formal proof of tenant isolation or independent penetration-test assurance. Customers must still choose appropriate provider permissions and protect their applications and Gateman signing material.

The boundary differs by capability. Some operations relay a provider request through Gateman, while presigned storage URLs are used directly with the storage provider after issuance. A presigned URL has its own expiry and does not become a general guarantee about the status of previously issued URLs after credential changes.

Runtime diagnostics use application-owned logs with sensitive-looking fields filtered and defined retention behavior. This is a protective control, not a claim that logs can never contain sensitive information. See [Data retention](https://docs.getgateman.com/data-retention/) for the documented retention model.

## Team access and revocation

Account owners manage console access through the existing team model of owners and members. A member can have access to all applications or selected applications, and members can be disabled. Database-backed authorization checks enforce application-access changes on the next authenticated console request, including a request made through an existing session; revocation does not require waiting for that session to expire.

This does not automatically log a user out or cancel an in-progress request. Team membership controls console access and is distinct from an application's runtime authentication, so changing a team member's access does not rotate application signing credentials or disable the application's runtime authentication. See [Teams and access management](https://docs.getgateman.com/teams-and-access-management/) for the complete team workflow.

## Understanding the trust and availability trade-offs

Gateman is a trusted service. It stores, decrypts, and uses supported provider credentials, which reduces how widely those credentials must be distributed but makes Gateman a trusted dependency. Applications still hold sensitive Gateman signing credentials. Gateman is not zero trust or zero knowledge, and it is not an IAM replacement or a claim of independent security certification.

Operations performed through Gateman depend on Gateman being available. Applications should handle failed or unavailable Gateman requests according to their own requirements; direct provider integrations have their own availability dependencies as well. Gateman does not advertise an uptime guarantee or failover behavior on this page.

If a team stops using Gateman, supported integrations can be moved to direct provider APIs and SDKs. [Removing Gateman](https://docs.getgateman.com/removing-gateman/) describes the customer-controlled transition. Regional endpoints, storage locations, geographic failover, regional key isolation, and data-residency guarantees are not promised here; those properties depend on the deployed architecture and should be verified separately.

## Related security references

- [Using Gateman with coding agents](https://docs.getgateman.com/using-gateman-with-coding-agents/)
- [Authentication](https://docs.getgateman.com/authentication/)
- [Contract v1](https://docs.getgateman.com/contract-v1/)
- [Idempotency](https://docs.getgateman.com/idempotency/)
- [Rate limits and concurrency](https://docs.getgateman.com/rate-limits-and-concurrency/)
- [Teams and access management](https://docs.getgateman.com/teams-and-access-management/)
- [Data retention](https://docs.getgateman.com/data-retention/)
- [Removing Gateman](https://docs.getgateman.com/removing-gateman/)
- [Capability references](https://docs.getgateman.com/capabilities/email.send/)