Units
1. Prompt Injection and Layered Defense 2. Data Leak Prevention and PII Masking 3. Output Verification and Human Inspection 4. Access Control, Identity and Secret Management 5. Logging, Audit Trail and Provenability 6. Model Risk Management and Red Team 7. Supplier Evaluation and Third Party Risk 8. On-Prem, VPC and Openweight Hosting 9. Continuous Monitoring, Observability and Drift 10. Incident Response and Business Continuity 11. Enterprise AI Security Checklist and Governance
Unit 4 / 11

Access Control, Identity and Secret Management

Gains:

  • Ability to separate authentication and authorization and apply minimum authorization with RBAC/ABAC
  • Ability to avoid mixed proxy risk by running the model in the user context
  • Ability to store and rotate API keys with the secret management system

A significant portion of attacks on an AI system begin not with “tricking” the model, but with a stolen API key or an over-authorized account. This layer of security comes from classical information security, but adds new risks in the context of AI: a model calls a ride on someone else's behalf, a service account accesses all data, a key leaks to GitHub. In this unit, we will learn how to narrow down access to the AI ​​system with authentication, authorization (RBAC/ABAC), minimum authorization and secret management.

Difference Between Authentication and Authorization

The two terms are often confused:

  • Authentication: "Who are you?" — proving that the user/service is really who they claim to be (password, token, certificate, MFA).
  • Authorization: "What can you do?" — determine which resource/action the authenticated party can access.

The critical subtlety in AI systems is this: when the model is performing work on behalf of a user, is it operating with the authority of that user or with a broad service account? The latter is dangerous — because the model tricked by the injection gains full access to the service account.

Caution: "Confused deputy" problem: a low-authority user indirectly accesses data that he cannot access by outsourcing a high-authority model. The model should always operate within the context of the user's authority, not his own broad authority.

RBAC and ABAC

  • RBAC (Role-Based Access Control): Access depends on the user's role. The "support specialist" role can read customer notes, but cannot delete them. Simple and common.
  • ABAC (Attribute-Based Access Control): Access depends on attributes: the user's department, the privacy label of the data, the time of day, the network from which the request comes. More fine-tuned but more complex.

Most organizations start with RBAC and deepen to ABAC for sensitive data. Rule of thumb for AI: the model should filter every agent it calls and every data it accesses based on the role/attributes of the user making the request.

Step by Step: Exercising Minimal Authority

  1. Take inventory. What tools does the model call, what data does it access? List them all.
  2. Justify each access. “Does this assistant really need delete authority?” Otherwise, remove it.
  3. Read-only default. The model should be able to read by default; Require write/delete separate, narrow-scope token.
  4. Move user context. Call the vehicle with the user's authority, not with the service account.
  5. Short-lived credential. Use short-lived, auto-renewing tokens instead of long-lived keys.

Secret Management

A secret is credentials that must remain secret, such as an API key, password, token, or certificate. The most common accident in AI projects is when the model provider's API key is embedded in the code and leaks into version control (Git).

Correct application:

  • Never embed keys in code; Use an environment variable or a secret management system (a service that stores keys encrypted and controls access).
  • Rotation: Renew keys at regular intervals (e.g. every 90 days); If leak is suspected, cancel immediately.
  • Scope reduction: Each switch has only the required service and required authorization.
  • Audit: Log who used the key, when, and where.

Four Copiable Templates

Access review control prompt:

For each tool in the tool list below, evaluate:- Is this tool REQUIRED to perform this assistant's job? (yes/no) - Is it read-only or write/erase? - Is this tool called with the user's authority or service account? Mark unnecessary or excessively authorized ones as "REMOVE/REDACT".<tools>{{ tool_list }}</tools>

Secret leak scanning prompt:

Find anything that could be a hardcoded secret in the following code snippet: API key, password, token, connection string, private key. Give row and type for each. COPY value into response;mask (first 4 characters + ***).<code>{{ source }}</code>

Least authority decision rule:

When a new tool/access request arrives, ask:1. Can the task be performed without this access? -> If yes: REJECT2. Is read-only enough? -> If yes: GRANT write permission3. Can the scope be narrowed down to a single source? -> If yes: daratThe default answer is "no"; Access is gained by reason.

Rotation calendar reminder:

For each secret, record: owner, creation date, expiration, scope. Report any key that has exceeded 90 days or has not been used for 30 days as a "ROTATION/CANCELLATION CANDIDATE".

Weak Prompt / Strong Prompt

poor approach

Strong approach

Model accesses all data with a single service account

The model accesses with the authority of the user making the request

API key is embedded in the code, it never changes

Rotation in key secret manager, 90 days

Broad "do anything" authority to the assistant

Read-only default, write narrowly

Accesses are never reviewed

Regular access review and revocation

Three Mini Cases

Case 1 — Leaked mixed proxy data. An in-house assistant was working with a service account that had access to all employee records. An intern user accessed data that he would not normally see by saying "summarize the executive salary table"; because the model questioned it in the context of its own broad authority, not the user's. Once the user context was adjusted to be moved, the intern was able to pull recordings that only he or she could see.

Case 2 — Leaked key, 190,000 TL bill in 2 weeks. A developer embedded the model API key in a helper script and pushed it to a public repository. A bot found the key in 40 minutes and used it for two weeks; The bill reached 190,000 TL. When the key was moved to the secret manager, connected to rotation, and repository scanning was added, the incident did not reoccur.

Case 3 — Read-only default prevented interrupt. A DevOps assistant received a "reset production database" command via prompt injection. However, the assistant was given only a read-only token; write/erase was in a separate approved flow. The command was rejected with authorization error and the event was logged as an alarm; There was no data loss.

Tip: Make "no" your default answer to a new access request. Access is something gained through justification; Giving everyone wide and then cutting back is almost never done and the risk accumulates.

Common mistakes

  • Running the model with a large service account and losing the user context (mixed proxy).
  • Embedding the API key in the code and leaking it into version control.
  • Not rotating the keys at all ("working, don't touch").
  • Giving the assistant write/delete permissions by default.
  • Granting access once and never reconsidering it.
  • Confusing authentication with authorization and assuming "he's logged in, he can access everything".

In summary

  • Authentication is a question of “who are you”, authorization is a question of “what can you do”; In AI, both must operate in the context of the user.
  • The model should operate with the authority of the user making the request, not with its own broad authority (avoiding the risk of mixed agency).
  • Start with RBAC, deepen with ABAC on sensitive data; Make minimal authority the default.
  • Don't bury secrets in code; store it in the secret manager, narrow it down and put it into regular rotation.
  • The read-only default and narrow write greatly limit the impact of injection.

Application task

List all the tools and data your AI assistant accesses. Answer three questions for each: (1) Is it really necessary? (2) Is read-only enough? (3) Does it run in user context? Then search for all hard-coded secrets (via the scan prompt above) and write a rotation plan for each key you find. Remove at least one unnecessary authorization.

checklist

  • [ ] The model runs in the authority context of the user making the request.
  • [ ] Tool and data access has been narrowed down to the principle of least privilege.
  • [ ] Write/erase is separate from read-only, authenticated and narrow.
  • [ ] No secrets are buried in the code; It is kept in the secret manager.
  • [ ] There is a rotation schedule and cancellation procedure for keys.
  • [ ] Accesses are reviewed regularly.
Previous Next