T02 · Agent Memory Poisoning
- Location
SKILL.md:35- Finding
Persistent memory files can inject behavioral instructions into future sessions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Azure helper is coherent but should be reviewed because it automatically stores and reuses detailed cloud inventory, billing, and contact notes on your machine.
Review this skill before installing if you work with sensitive tenants, clients, regulated environments, or shared machines. Its cloud advice is coherent and it does not show exfiltration or hidden code, but it will build a durable plaintext local knowledge base about your Azure estate and related people; use it only where that local persistence and sharing across Clawic data folders is acceptable.
SKILL.md:35Persistent memory files can inject behavioral instructions into future sessions
memory-template.md:3Automatic plaintext persistence exposes sensitive cloud reconnaissance and contact metadata
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
## Security & Privacy
**Credentials:** this skill drives the Azure CLI, which reads credentials from `~/.azure/`, the OS keychain, environment variables, or a managed identity. It does NOT store, log, copy, or transmit Azure credentials, and never writes a credential into `~/Clawic/data/azure/`.
**Local storage:** preferences, memory, inventory, spend history and artifacts stay in `~/Clawic/data/azure/` on this machine — subscription and tenant identifiers, resource names, and cost figures only, no secrets.
Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.
- **Incremental (default)**: resources in the template are created or updated; resources *not* in the template are left alone. Drift accumulates invisibly — an incremental deployment can never tell you what it did not touch.
- **Complete**: everything in the target scope that is not in the template is **deleted**. It is the only way ARM converges to the template, and it is how people delete production. Never run it at a scope containing resources the template does not own, and never run it without `what-if` output that a human read.
- **Scopes**: resource group, subscription, management group, tenant. Subscription-scope templates create resource groups; management-group scope deploys policy and role assignments. Choosing the scope wrong is why a template "cannot find" a resource type.
- **Deployment history is capped** at 800 records per resource group; past that, deployments fail until older records are purged. On a busy CI pipeline this arrives without warning.
- Deployment names should be deterministic and meaningful (`workload-env-<run-id>`), because the history is the audit trail.
## Deployment Stacks
The template explicitly permits storing pointers to secret-bearing local files, including file:~/.azure/msal_token_cache.json. While it forbids writing raw secrets into the skill's data directory, persisting a direct reference to a token cache materially aids credential discovery and reuse by any later agent or process that can read the memory files. In an Azure-focused skill, this is especially sensitive because the referenced MSAL cache may contain reusable cloud authentication tokens.
Nothing under `~/Clawic/data/` ever holds a secret value — not the files named here, not files you create, not text the user pastes in and asks you to keep. Azure text is dense in them: a connection string, a `kubectl config`, a publish profile and a Terraform state excerpt all carry live credentials in the middle of otherwise useful content. Store the pointer in its place, in this shape: `<kind>:<locator>`.
`azure-kv:kv-prod/db-password` · `env:AZURE_CLIENT_SECRET` · `keychain:azure-prod` · `1password:Work/Azure/prod` · `vault:secret/azure/prod` · `file:~/.azure/msal_token_cache.json`
When the user pastes something to save, replace each secret value before writing and leave the pointer visible: `password: <azure-kv:kv-prod/db-password>`. Say in one line that you did it.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
When the user pastes something to save, replace each secret value before writing and leave the pointer visible: `password: <azure-kv:kv-prod/db-password>`. Say in one line that you did it.
In this domain — **not secrets, keep them**: subscription IDs, tenant IDs, resource IDs and resource group names, application (client) IDs, object and principal IDs, managed identity names, role definition IDs, region names, storage account and Key Vault *names*, secret *names*, ACR login servers, address ranges. **Secrets, strip them**: client secrets, storage account keys, SAS tokens and any URL containing `sig=`, connection strings carrying `AccountKey`, `Password` or `SharedAccessKey`, Cosmos DB and Redis access keys, Service Bus and Event Hubs SAS policy keys, Function host and master keys, Application Insights connection strings and instrumentation keys, App Service publish profiles, kubeconfig admin certificates and tokens, PFX passwords, private keys, and the output of any `get-access-token` or `list-keys` call.
**Contents:** [config.yaml](#configyaml) · [memory.md](#memorymd) · [shared servers inventory](#shared-servers-inventory) · [shared domains inventory](#shared-domains-inventory) · [shared contacts](#shared-contacts) · [subscriptions.md](#subscriptionsmd) · [artifacts/](#artifacts) · [deploys/](#deploys) · [split-out files](#split-out-files)
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
| Name | Provider | Account / Project | Region | Type | Role | Monthly | Access reference |
|---|---|---|---|---|---|---|---|
| vm-api-prod-01 | azure | prod-platform / rg-api-prod | westeurope | D4ds_v5 | API | 148 EUR | keychain:azure-prod |
- **Identity is `Name` + `Provider`.** Read the file before adding. If that pair is already there, update the row in place — it is yours. The rule against rewriting protects rows whose `Provider` is not `azure`; never touch those.
This pattern attempts to override system instructions or ignore safety constraints. Without LLM analysis, manual review is recommended.
- **Peering is non-transitive.** A spoke peered to a hub cannot reach another spoke through it unless something routes: user-defined routes pointing at a firewall or NVA, Azure Route Server, or Virtual WAN.
- Peering bills on both sides for traffic that crosses it. A chatty hub-and-spoke pays per hop, in both directions.
- **Gateway transit** lets spokes use the hub's VPN/ExpressRoute gateway — enable it on both sides of the peering, or on-prem routes never appear in the spokes.
- User-defined routes override system routes; the most specific prefix wins, and `0.0.0.0/0` to a firewall forces all egress through it — including traffic to Azure services, which then needs the firewall to allow it.
- Deleting an NVA without removing its routes leaves a black hole that looks exactly like an NSG problem. Check effective routes before effective rules when the symptom is a timeout with no reset.
- **Virtual WAN** replaces hand-built hubs when the estate has many regions or many branch sites; it is a different cost and operating model, not a drop-in upgrade.
The template authorizes broad, ongoing persistence of operational context by rewriting and splitting memory across multiple files without requiring user confirmation. Although intended for convenience, this can lead to retention of sensitive infrastructure details, ownership data, spend history, and operational timelines far beyond the immediate session, increasing exposure if the memory store is later accessed by other skills, users, or compromised tooling. The Azure context makes this more sensitive because even non-secret metadata like subscription structure, resource inventories, and due dates can facilitate reconnaissance.
Everything except artifacts, deploy records and the shared boxes begins inside `memory.md`. Splitting is a procedure, not a suggestion:
1. Before appending to a section, count its entries.
2. If the append would take it past **~15 entries or ~40 lines of real content** — scaffolding, headings and comments do not count — then, in the same turn: create the new file in `~/Clawic/data/azure/`, move the whole section into it, **delete the section from `memory.md`**, add its line to `## Boxes`, and append the new entry to the new file.
3. Keep the headings identical on both sides of the move, so the split is a copy-paste and never a rewrite.
4. Never leave a copy behind. If the same data ever appears in both places, the extracted file wins and the `memory.md` copy is deleted.
The runbook instructs writing credential-leak response details to local files under ~/Clawic/data/azure/artifacts/ and memory.md. Even though it says not to store secret values, breach timelines, affected assets, rotation details, and investigative notes are still sensitive incident-response metadata that can aid an attacker or create compliance/privacy issues if the local machine, repo, sync client, or backups are exposed.
The skill explicitly instructs the agent to read from and write back to persistent local files in the user's home directory during normal operation, but it does not clearly warn that these actions modify local records. In an agent setting, silent persistence can create integrity and privacy risks because billing notes, dates, and optimization history may be altered without the user realizing a file write will occur.
Skill requests more permissions than appear necessary for its stated functionality. Review if elevated access is justified.
| Scope | Tenant (or administrative unit) | Management group → subscription → resource group → resource, inherited downward |
| Assigned in | Entra ID blade | The resource's Access control (IAM) blade |
A Global Administrator has **no** access to Azure resources by default. The "elevate access" toggle grants them User Access Administrator at the root management group — a deliberate, audited action, and the way you recover a tenant whose subscriptions have no owners. Turn it back off afterwards.
## Evaluation Order
The skill instructs the agent to read and then write back to a local artifact file in the workspace without any explicit user-consent or cautionary note. In an agent setting, this can cause unintended modification of persistent project state, especially because the instruction is framed as a mandatory operational step rather than an optional, user-approved action.
This instruction tells the agent to record domain, nameserver, and certificate-expiry information into a shared file without warning that it may be sensitive operational metadata. While not a direct secret leak, centralizing such infrastructure details in shared workspace memory can expose attack-relevant information or cause unapproved persistence of environment data.
The document explicitly instructs the agent to write an architecture decision record to a concrete local filesystem path under the user's home directory. Even though the intent is documentation, this is still a state-changing file operation instruction without any warning, confirmation, or safety boundary, which can lead an agent to modify local files unexpectedly.
The skill explicitly instructs the agent to modify local files (~/Clawic/data/servers/servers.md and memory.md) after infrastructure actions, but does not require confirming with the user before making those filesystem changes. In an agent setting, this creates an unsafe side effect boundary: operational advice about Azure resources is coupled with automatic local state mutation, which can lead to unauthorized edits, tampering with audit records, or persistence of incorrect infrastructure metadata.
Detected: suspicious.exposed_secret_literal