Apply for AI Grants India

Why AI API key management needs a different approach

AI credentials are not ordinary configuration values. A leaked key can expose paid model access, create an unexpected bill, reveal prompts and user data, or become a route into connected services. Generative AI applications also tend to use several providers, embeddings databases, observability tools, and agent integrations, increasing the number of secrets a team must control.

For Indian startups, student teams, agencies, and independent builders, the goal is not to build an expensive security programme on day one. It is to establish clear ownership, minimise access, and make the safe path easy across development, staging, and production. This becomes especially important when building AI agent frameworks for Indian developers, where a single workflow may call multiple external APIs.

First principle: never put a provider key in the client

A model-provider key should remain on a server you control. Do not embed it in:

• Browser JavaScript or mobile application binaries
• Public GitHub repositories, notebooks, or demo websites
• React Native, Flutter, or Android/iOS application packages
• Front-end environment variables that are bundled during a build
• Support tickets, screenshots, or shared chat messages

Use this architecture instead:

1. The web or mobile client authenticates the user with your application.
2. Your backend authorises the request and applies quotas.
3. The backend retrieves the provider credential from a secrets store.
4. The backend calls the AI provider and returns only the required result.

A proxy is not automatically secure. Add authentication, request validation, rate limits, maximum token limits, timeout controls, and provider-specific allowlists. For voice products, for example, these controls matter before you connect a provider to workflows similar to those used in AI voice solutions for Indian real estate developers.

Separate credentials by environment and workload

Create distinct credentials for local development, testing, staging, and production. Within production, separate keys by service or risk boundary where the provider supports it. A key used for batch embeddings should not have the same permissions or budget as a customer-facing chat service.

Use naming that helps operators identify ownership without exposing the secret itself, such as prod-support-bot-mumbai or staging-document-search. Record the owner, service, creation date, provider, permissions, and planned expiry in an inventory. This inventory is useful during an incident and prevents abandoned keys from remaining active indefinitely.

For small teams, a practical baseline is:

• One key per environment
• Separate production keys for materially different products
• No shared personal keys in deployed systems
• Least-privilege permissions wherever provider controls exist
• A documented owner and emergency contact for every production key

Teams operating larger scalable machine learning infrastructure for developers should move from informal environment files to centrally managed identities and workload-based access.

Store secrets correctly across the development lifecycle

Environment variables are acceptable for local development when the .env file is excluded from version control and protected by the developer’s operating system. They are not a complete production secrets strategy. Never commit .env files, generated build artefacts, Terraform state containing plaintext values, or CI logs that print configuration.

For production, use a secrets manager such as HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or the equivalent facility offered by your hosting provider. Applications should retrieve secrets at runtime through an authenticated workload identity rather than keeping long-lived credentials in container images or deployment manifests.

Add preventive controls to the repository:

• Enable secret scanning in GitHub, GitLab, or your source-control platform.
• Install a pre-commit scanner such as Gitleaks or detect-secrets.
• Mask secret values in CI/CD logs.
• Review pull requests for accidental hardcoding and unsafe debug output.
• Treat notebooks and .history directories as possible leak sources.

When building open-source AI tools for Indian developers, document setup with placeholder values and a .env.example file. Never ask contributors to paste real provider credentials into issues or pull requests.

Rotate keys and prepare for leaks

Rotation is only useful if your application can change credentials without downtime. Keep two active keys briefly during a planned rotation: create the replacement, deploy it, verify traffic, revoke the old key, and confirm that no service still depends on it. If the provider supports short-lived tokens or workload identity, prefer those over permanent keys.

Define an incident runbook before a leak occurs:

1. Revoke or disable the exposed credential immediately.
2. Check provider logs, usage, destinations, and spend from the exposure window.
3. Identify whether prompts, uploaded files, personal data, or other secrets were sent.
4. Deploy a replacement key through the approved secrets path.
5. Remove the credential from Git history and invalidate cached artefacts where possible.
6. Notify affected customers or partners when required by your contracts or applicable obligations.
7. Record the root cause and add a control that prevents recurrence.

Assume that a key committed to a public repository is compromised, even if the commit was deleted moments later. Search tools and provider alerts can discover exposed credentials quickly, but they should supplement—not replace—revocation.

Control usage, privacy, and cost

Security includes controlling what the key can do and what your application sends. Enforce per-user and per-tenant quotas, request-size limits, model allowlists, concurrency limits, and monthly spending alerts. Log request metadata such as service, model, latency, token counts, status, and cost estimate, but avoid logging raw prompts, responses, uploaded documents, or credentials by default.

For Indian applications, map data flows before sending personal, financial, health, education, or business information to an external model. Redact identifiers where possible, define retention periods, and review provider terms and data-processing commitments. Keep access to logs restricted and record administrative actions. A cheaper model is not a security control; use model routing only after privacy, quality, and failure behaviour are understood.

A practical production checklist

Before launch, verify that:

• No provider key reaches a browser, mobile package, repository, image, or notebook.
• Production and non-production credentials are separate.
• Secrets are stored in a managed vault or equivalent platform service.
• Workloads access secrets through identity-based permissions.
• Rate, token, concurrency, and spend limits are configured.
• Secret values are masked in application and CI/CD logs.
• Provider usage alerts reach an owner who can act.
• Rotation and emergency revocation have been tested.
• Prompts and responses are excluded from logs unless there is a defined, protected need.
• The team knows how to report a suspected exposure.

If you are comparing providers for a production application, evaluate credential scopes, audit logs, regional availability, retention controls, service limits, and billing—not just model quality. A comparison such as Claude vs Gemini API for developers in India is most useful when these operational factors are part of the decision.

Build the habit early

A two-person team can implement strong AI API key management without enterprise tooling: keep secrets out of the client and repository, use separate keys, enable scanning, restrict access, monitor spend, and rehearse revocation. As usage grows, centralise secrets, adopt workload identity, add environment-level approvals, and review data handling with legal and security stakeholders.

Good key management protects more than an API credential. It limits financial exposure, reduces the blast radius of mistakes, supports responsible handling of Indian user data, and gives builders confidence to ship AI features without creating an avoidable operational risk.