Family Guides
AWS2-SEC: Secrets, Credentials, And Sensitive Data Handling
AWS2-SEC is about keeping secrets and sensitive information from becoming easy for agents to copy, expose, store, log, or send somewhere unsafe.
In ordinary business terms, this family asks: can the agent see passwords, tokens, private keys, browser sessions, confidential files, customer records, regulated data, private source code, screenshots, transcripts, or sensitive summaries; where are those things allowed to live; what must never be copied into prompts, memory, logs, traces, notes, or evidence; and what proof can a reviewer see without exposing the sensitive material again?
This matters because agentic work often crosses boundaries. An agent may read files, inspect code, use a browser, call a connector, summarize documents, write notes, save memory, produce logs, or send external messages. A secret or private record can move from a safe location into a prompt, from a prompt into a transcript, from a transcript into memory, from memory into a handoff, or from a handoff into an evidence packet. Reviewers need evidence that sensitive locations are known, sensitive exports are classified, access is limited, movement is gated, evidence is redacted, and high-impact workflows are tested.
What This Family Covers
In scope:
- Secrets, credentials, tokens, private keys, API keys, SSH keys, session cookies, OAuth tokens, service-account credentials, model-provider keys, connector tokens, and other values that can grant access.
- Personal data, regulated data, confidential business data, tenant data, customer data, intellectual property, private source material, sensitive derived outputs, screenshots, transcripts, summaries, and evidence payloads.
- Places where agents may encounter sensitive material, including local files, repositories, environment variables, keychains, browser sessions, SaaS connectors, retrieval sources, memory, logs, traces, generated files, screenshots, source systems, and evidence stores.
- Locations where secrets and sensitive data must not be stored unless explicitly protected, such as prompts, tool outputs, public notes, portable project context, skill metadata, memory, logs, traces, summaries, and review packets.
- Action classes that may export, reveal, copy, persist, summarize, screenshot, transmit, or otherwise move sensitive content outside an approved boundary.
- Least-privilege sensitive access, including scope, duration, connector permissions, retrieval access, tool access, short-lived credentials, entitlement review, and revocation where practical.
- Approval, denial, DLP, redaction, de-identification, tokenization, scanning, derived receipts, and equivalent controls before sensitive material moves to public files, external systems, shared channels, lower-trust tools, lower-trust models, or unapproved memory or retrieval locations.
- High-impact tests and exercises for denied exfiltration, token teardown, credential revocation, entitlement checks, redaction behavior, and sensitive output handling.
- Retained evidence of policy, redaction behavior, approvals, denials, exceptions, and sensitive-data export outcomes without retaining raw sensitive payloads unless explicitly required and protected.
- Integration with managed secret stores, DLP, endpoint controls, identity systems, SIEM, MDM, EDR, CASB/SSE, or equivalent enterprise controls where sensitive production data or privileged credentials are involved.
Out of scope:
- Full legal analysis of privacy, data protection, biometrics, employment monitoring, sector-specific regulation, cross-border transfer, discovery, or retention duties.
- Complete data-classification or records-management program design.
- Deciding the complete scoped system boundary, resource inventory, and owner map. That belongs mostly to
AWS2-SCP. - Deciding whose identity and authority an agent uses when accessing sensitive systems. That belongs mostly to
AWS2-DEL. - Filesystem, browser, network, shell, repository, sandbox, and endpoint boundaries as a general execution-control problem. Those belong mostly to
AWS2-WSB. - Runtime approval and denial policy as a whole. That belongs mostly to
AWS2-RUN, thoughAWS2-SECdefines sensitive action classes that runtime policy should gate. - Source trust for tools, connectors, skills, packages, prompt packs, and supplier components. That belongs mostly to
AWS2-SRC, though source-trust records should identify sensitive permissions and credential use. - Prompt, memory, retrieval, and instruction-boundary control as a whole. That belongs mostly to
AWS2-CTX, though this family defines sensitive context that should not be stored or exported unsafely. - Complete log-retention, receipt integrity, reconstruction, or tamper-evidence design. That belongs mostly to
AWS2-LOG, though sensitive access and export records should be retained safely. - Complete validation-program design, red-team method, or finding lifecycle. That belongs mostly to
AWS2-VAL, though this family names the sensitive-data tests that matter.
Level Summary
Levels are cumulative. Level 2 builds on Level 1, and Level 3 builds on both.
| Level | Plain-language meaning | Why this level exists | Typical evidence |
|---|---|---|---|
| Level 1 | The organization knows where agents might encounter secrets or sensitive data, where that material must not be copied, and which actions could move it outside the approved boundary. | Sensitive material cannot be protected until locations, prohibited storage paths, and risky movement actions are visible. | Sensitive-location inventory, prohibited-storage policy, data-category register, sensitive-export action taxonomy. |
| Level 2 | Production workflows limit sensitive access, require approval or prevention before sensitive movement, and keep useful evidence without raw sensitive payloads. | Managed production use needs repeatable controls, not only a warning that agents should be careful with private data. | Least-privilege access record, connector scope review, approval receipt, DLP event, redaction policy, derived evidence packet. |
| Level 3 | High-impact workflows test secret and sensitive-data controls, retain redacted evidence for material periods, and integrate with managed enterprise safeguards where appropriate. | High-impact environments need stronger proof that sensitive paths were tested, evidence remains reviewable, and ad hoc local handling is not the only control. | Denied-exfiltration test, token teardown test, redaction regression result, retained export receipt, secret-store audit log, DLP or endpoint integration note. |
Candidate Controls
AWS2-SEC-L1-001: Secret And Sensitive-Data Location Inventory Level 1
Requirement summary
Identify likely places where agents could access secrets, credentials, tokens, keys, and sensitive data directly or indirectly. Include files, environment variables, secret stores, browser or application sessions, connector scopes, memory, logs, retrieval sources, and evidence artifacts where applicable.
Why it exists
Teams often focus on obvious data stores and miss agent-created or agent-accessible paths. A token in an environment variable, a customer file in a synced folder, a browser session, a private repository, a screenshot, a local memory record, or a compliance export can all become sensitive input to an agent. Reviewers need a map before they can decide what to protect.
Why this level
This belongs at Level 1 because inventory is the foundation. The inventory does not prove the sensitive locations are safe, complete, or well controlled, but it gives reviewers and owners the starting point for prohibited-storage rules, least-privilege access, export gates, and tests.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Secret and sensitive-data location inventory | Workspace or endpoint owner with runtime owner input | Before production use and after adding repositories, connectors, data sources, memory, logging, or evidence exports | Files, repositories, environment variables, secret stores, browser or app sessions, connector scopes, retrieval sources, memory stores, logs, traces, generated files, screenshots, and evidence artifacts that may expose sensitive material | Identifies likely locations; does not prove all hidden, supplier, browser, personal-account, or provider-retained locations are covered. |
| Data-category register | Data owner or governance owner | During scope review and after data-category changes | Categories such as credentials, customer data, regulated data, confidential business data, tenant data, source code, transcripts, images, and sensitive derived outputs | Supports classification; does not prove legal classification or privacy-law compliance. |
| Discovery or scan summary | Security, platform, or evidence owner | Before review and during periodic sampling | Repository scans, DLP discovery, cloud data discovery, endpoint review, connector scope review, or manual checks used to find sensitive locations | Supports location discovery; does not prove scanners detect every secret or data type. |
AWS2-SEC-L1-002: Prohibited Secret And Credential Storage Level 1
Requirement summary
Define where secrets and credentials must not be stored, including portable project context, public notes, skill metadata, prompts, tool outputs, logs, memory, traces, summaries, and evidence artifacts unless explicitly protected.
Why it exists
Secrets are often leaked by copying, not only by hacking. An API key can be pasted into a prompt, printed in tool output, saved in a transcript, remembered by an agent, included in a summary, committed to a repository, or attached to an evidence packet. A simple list of "never store secrets here" prevents reviewers from treating unsafe copies as normal.
Why this level
This belongs at Level 1 because every scoped system should be able to state forbidden storage locations before it has full automation. The control sets the policy boundary that later redaction, scanning, memory controls, and evidence-review checks can enforce.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Prohibited-storage policy | Governance owner with workspace, runtime, and evidence owner input | Before production use and after evidence, logging, memory, or context changes | Locations where secrets and credentials must not appear, including prompts, logs, traces, memory, notes, skill metadata, public files, summaries, screenshots, and review packets unless explicitly protected | Defines expected handling; does not prove past records are clean. |
| Approved secret-store or credential-handling note | Security or platform owner | Before credentials are made available to agents and after secret-store changes | Where secrets may live, how agents retrieve or request them, and which storage locations are explicitly approved | Supports safe-storage review; does not prove all runtime paths use the approved store. |
| Evidence export checklist | Evidence or audit owner | During evidence preparation and sampling | That review packets, screenshots, traces, transcripts, logs, and summaries were checked for secrets or replaced with safe placeholders or derived values | Supports evidence hygiene; does not prove every retained artifact is free of secrets. |
AWS2-SEC-L1-003: Sensitive Export Action Classification Level 1
Requirement summary
Identify action classes that could export, reveal, copy, persist, or transmit sensitive data outside the approved boundary. Include derived sensitive outputs, screenshots, summaries, tool results, and external communications where applicable.
Why it exists
Sensitive data does not only leak through a direct "upload file" action. Agents may summarize a private document, paste a code snippet into an external service, take a screenshot, write a handoff, send a Slack message, create a ticket, call a connector, store a transcript, or produce a derived output that still reveals private information. These action classes need to be named before runtime policy can gate them.
Why this level
This belongs at Level 1 because action classification is basic policy vocabulary. It does not require automated DLP or perfect detection, but it lets reviewers ask which sensitive movements are allowed, denied, approved, redacted, or logged.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Sensitive-export action register | Runtime platform owner with data owner input | Before production use and after adding tools, connectors, communication channels, or output modes | Action classes such as external sends, public file writes, shared-channel posts, lower-trust model calls, retrieval writes, memory writes, screenshots, summaries, tool results, and generated handoffs | Identifies risky action classes; does not prove all actions are detected or controlled. |
| DLP or channel map | Security, endpoint, or SaaS owner | Before production use and after channel or DLP changes | Which channels, apps, endpoints, repositories, browsers, connectors, and storage targets are covered by DLP or equivalent review | Supports coverage review; does not prove DLP catches transformed, image, voice, or out-of-band movement. |
| Boundary decision note | Governance or data owner | During scope review and exception review | Approved destinations, lower-trust destinations, prohibited destinations, and exception paths for sensitive content | Defines boundary intent; does not prove a destination is legally or contractually sufficient. |
AWS2-SEC-L2-001: Least-Privilege Sensitive Access Level 2
Requirement summary
Restrict agent access to secrets, credentials, tokens, and sensitive data to the minimum necessary for the approved workflow. Constrain scope, duration, connector permissions, retrieval access, and tool access where practical.
Why it exists
A local agent, hosted assistant, coding agent, or cloud agent may inherit more access than it needs: broad filesystem access, browser sessions, environment variables, CI secrets, SaaS permissions, repository permissions, or connector scopes. Least privilege limits the amount of damage that a mistaken prompt, unsafe tool, poisoned context, or compromised connector can cause.
Why this level
This belongs at Level 2 because production use should move beyond inventory and policy into repeatable access control. It builds on Level 1 by using the location inventory and export classification to reduce actual sensitive access.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Sensitive access policy or entitlement review | Security, identity, workspace, or data owner | Before production use and during periodic review | Which agents, identities, connectors, tools, retrieval corpora, repositories, files, and data categories are permitted for the approved workflow | Supports least-privilege review; does not prove runtime behavior never exceeds intent. |
| Connector, OAuth, IAM, or secret-store scope record | Runtime platform, SaaS, cloud, or connector owner | Before enabling the workflow and after permission changes | Scope, duration, roles, token class, secret-store policy, retrieval access, connector permissions, and revocation path | Shows configured scope; does not prove source-system permissions are least privilege unless source permissions are also reviewed. |
| Short-lived credential, rotation, or revocation record | Security or platform owner | During operation and after credential changes or incidents | Lease, rotation, expiration, revocation, or teardown behavior for credentials used by the workflow | Supports credential lifecycle review; does not prove credentials were never copied elsewhere. |
AWS2-SEC-L2-002: Sensitive Movement Approval Or Prevention Level 2
Requirement summary
Prevent or require approval before agents transmit sensitive data, credentials, or derived sensitive outputs to external systems, public files, shared channels, lower-trust tools, lower-trust models, or unapproved retrieval or memory locations.
Why it exists
Production workflows need an exit gate. An agent can make a sensitive movement quickly through email, chat, ticketing, browser upload, connector call, repository write, model call, memory write, screenshot, or generated summary. This control requires a denial, approval, DLP, or equivalent check before that movement crosses an approved boundary.
Why this level
This belongs at Level 2 because managed production use should have a repeatable gate or compensating review for sensitive movement. Level 1 names the export action classes; Level 2 expects the workflow to prevent or require approval for the risky ones.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Runtime approval or deny rule | Runtime platform owner with data owner input | Before production use and after policy changes | Sensitive movement action classes, triggering data categories, destination classes, approval roles, denial behavior, and fallback behavior | Supports policy review; does not prove every sensitive movement is detected. |
| DLP alert, block, override, or policy decision event | Security, endpoint, SaaS, or evidence owner | During operation and review sampling | Data category, channel, destination class, actor or agent, policy outcome, approval or override status, and timestamp without raw payload where practical | Supports selected event review; does not prove DLP prevents all leakage. |
| Sensitive export approval receipt | Evidence or audit owner with runtime owner input | During operation and after approved sensitive movement | Requested movement, data category, destination, reviewer, decision, conditions, redaction status, and execution outcome | Supports review of approved movements; does not prove legal sufficiency or data-minimization compliance. |
AWS2-SEC-L2-003: Redacted Or Derived Evidence Level 2
Requirement summary
Use scanning, redaction, derived receipts, structured summaries, or equivalent controls to keep evidence useful without exposing raw secrets, personal data, regulated data, confidential payloads, or unnecessary business-sensitive content.
Why it exists
Evidence can become a second leak. Reviewers need to know that a data export was blocked, a token was rotated, a sensitive file was accessed, or a summary was approved, but they usually do not need the full token, customer record, confidential document, or private screenshot. Derived evidence keeps the review useful while reducing exposure.
Why this level
This belongs at Level 2 because production evidence should be shareable with reviewers without spreading raw sensitive payloads. It builds on Level 1 prohibited-storage rules by applying them to logs, traces, summaries, screen captures, tickets, audit packets, and validation outputs.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Redaction or derived-evidence policy | Evidence, security, or governance owner | Before evidence collection and after evidence-schema changes | Which fields are removed, masked, tokenized, hashed, summarized, categorized, or withheld; who may access exceptions; and how reviewers still get enough context | Supports evidence design; does not prove redaction catches every sensitive value. |
| Sanitized evidence packet | Evidence or audit owner | During review sampling, testing, incidents, or release review | Data category, policy outcome, actor, destination, decision, redaction method, retained fields, withheld-material rationale, and reference to protected raw material if needed | Supports review without raw payloads; does not prove the underlying action was safe. |
| Scanner, redaction, or sampling result | Security, platform, or evidence owner | During evidence preparation and periodic review | Secret scanning, PII detection, DLP inspection, manual sampling, or redaction test result for evidence artifacts | Supports hygiene review; does not prove all retained evidence is safe. |
AWS2-SEC-L3-001: Secret And Sensitive-Data Control Validation Level 3
Requirement summary
Validate secret-handling and sensitive-data controls for high-impact workflows through testing, review, or controlled exercises. Include denied-exfiltration paths, token or credential teardown, entitlement checks, redaction behavior, and sensitive-output handling where applicable.
Why it exists
Sensitive-data controls often look good on paper and fail in edge paths. Tests can reveal that a scanner misses generated summaries, DLP ignores a screenshot path, a connector uses broad scopes, a token stays active after a run, or a redaction rule removes too much or too little.
Why this level
This belongs at Level 3 because high-impact workflows need evidence that controls were exercised, not only configured. The tests should use harmless fixtures, synthetic data, canary tokens, sandbox accounts, or protected test records rather than live secrets.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Denied-exfiltration test record | Validation or evidence owner with runtime and data owner input | Before high-impact production use, after material control changes, and during periodic validation | Fixture, attempted sensitive movement, expected denial or approval, actual outcome, receipt, finding, remediation, and retest status | Tests selected paths; does not prove all leakage paths are blocked. |
| Token teardown, rotation, or revocation test | Security, platform, or identity owner | During validation, after credential changes, and after incidents | That scoped credentials can be revoked, rotated, expired, or torn down and that agent access behaves as expected afterward | Supports credential lifecycle assurance; does not prove no copies exist in logs, memory, or external systems. |
| Redaction regression or sampling test | Evidence, security, or validation owner | During validation and after evidence-schema or data-type changes | That logs, traces, summaries, screenshots, transcripts, and review packets are sanitized enough for the intended reviewer group | Supports redaction confidence for tested artifacts; does not prove all future artifacts are safe. |
AWS2-SEC-L3-002: Retained Sensitive-Data Access And Export Evidence Level 3
Requirement summary
Retain evidence of sensitive-data access policy, redaction behavior, and relevant denied or approved export events for material production periods, without retaining raw sensitive payloads unless the assessment explicitly requires and protects them.
Why it exists
High-impact workflows need reviewable history. If a sensitive export is questioned later, reviewers need to know which policy applied, what was requested, who approved or denied it, what redaction occurred, what was retained, and whether exceptions were protected. Retaining raw payloads by default can create unnecessary risk, so the record should be useful without becoming a sensitive data store itself.
Why this level
This belongs at Level 3 because retention, custody, and redacted reconstruction are higher-assurance expectations. Level 2 creates useful redacted evidence; Level 3 requires that material records survive long enough for review, incident analysis, and reassessment.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Redacted sensitive export receipt | Evidence or audit owner | During operation and retained for the material review period | Data category, destination class, policy version, approval or denial, redaction state, actor or agent, timestamp, exception status, and outcome without raw payload where practical | Supports reconstruction of selected events; does not prove the exported data was lawful, minimized, or harmless. |
| Secret-store, DLP, endpoint, or audit log retention record | Security, platform, endpoint, SaaS, or evidence owner | During operation and periodic retention review | Retention period, owner, access controls, export format, redaction state, deletion or withholding rules, and evidence-custody path | Supports evidence availability; does not prove provider logs or hidden app state retain no raw content. |
| Protected raw-payload exception record | Governance, legal, security, or evidence owner | Only when raw sensitive material must be retained for a defined assessment, legal, or incident purpose | Why raw material was retained, who can access it, protection method, retention limit, deletion trigger, and review authority | Documents an exception; does not make raw retention safe by itself. |
AWS2-SEC-L3-003: Enterprise Secret, DLP, And Endpoint Control Integration Level 3
Requirement summary
Integrate with managed secret stores, data-loss prevention, endpoint controls, or equivalent enterprise controls where agent workflows involve sensitive production data, customer data, tenant data, regulated information, privileged credentials, or critical systems.
Why it exists
High-impact sensitive workflows should not rely only on ad hoc prompts, manual reminders, copied local tokens, or after-the-fact review. Managed secret stores, identity systems, DLP, endpoint controls, monitored channels, protected evidence stores, and equivalent safeguards give teams stronger ways to limit, detect, review, and revoke sensitive access.
Why this level
This belongs at Level 3 because enterprise integration is often harder than documenting policy. It requires coordination across runtime, endpoint, identity, data, security, evidence, and governance owners, and it should be expected where production-sensitive or privileged workflows are material.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Enterprise control integration note | Security, platform, endpoint, cloud, or runtime owner | Before high-impact production use and after architecture changes | Which managed secret store, DLP, endpoint, identity, SIEM, MDM, EDR, CASB/SSE, or equivalent controls apply to the scoped workflow and where gaps remain | Supports architecture review; does not prove every agent pathway is covered. |
| Managed secret or DLP policy export | Security, cloud, SaaS, endpoint, or data owner | Before review and after policy changes | Relevant secret-store policy, DLP rule, endpoint coverage, connector policy, audit export, or monitoring integration for the scoped workflow | Supports configuration review; does not prove product effectiveness in all channels. |
| Residual-gap and compensating-control register | Governance or security owner with runtime owner input | During readiness review and periodic reassessment | Uncovered paths, manual controls, exceptions, compensating measures, expiry, owner, and reassessment trigger | Supports honest claim limits; does not turn partial control coverage into complete assurance. |
External Mapping Notes
The completed crosswalk treats AWS2-SEC as a candidate-control family that maps to or supports evidence for selected sensitive-data, credential, privacy, least-privilege, data-access, DLP, and exfiltration concerns across external sources. These mappings are informative and bounded.
Relevant source signals include:
- OWASP AISVS and OWASP GenAI Security guidance signals around authorization, output handling, sensitive information disclosure, secret management, data-exposure testing, and interaction metadata.
- OWASP Agentic Skills Top 10 signals around excessive permissions, overbroad skill access, data leakage, unsafe external calls, and incident response for agentic skills.
- AIUC-1 public signals around agent identity, permissions, MCP and tool allowlists, deployment environment, DLP evidence, human review, and sensitive-output handling.
- NIST AI 600-1 and NIST AI RMF signals around data governance, privacy, misuse, provenance, risk measurement, and impact management for generative AI systems.
- ISO/IEC 23894 public metadata and descriptions as high-level AI risk-management input, with no detailed control claim from public text.
- Five Eyes agentic AI adoption guidance signals around just-in-time credentials, rollout gates, prompt and context risks, logging, rollback, data exposure, and careful use of agentic services.
- MITRE ATLAS signals around credential harvesting, exfiltration, data exposure, detection mapping, adversary scenarios, and red-team test design.
- Selected EU AI Act data, logging, cybersecurity, transparency, oversight, and due-diligence signals, with explicit legal-claim limits.
Formal Standard Link
Use this guide with the formal AWS2-SEC candidate requirements. If the guide and the standard draft disagree, the standard draft controls.