home / skills / yelmuratoff / agent_sync / security

security skill

safe

This skill helps enforce secure handling of secrets, auth data, and PII in Flutter apps by guiding storage, testing, and threat mitigation.

npx playbooks add skill yelmuratoff/agent_sync --skill security

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.4 KB

---
name: security
description: When handling secrets, authentication tokens, PII, or adding storage/network/logging that could affect user privacy.
---

# Security & Privacy

## When to use

- Storing or reading tokens/credentials/session data.
- Logging user actions, errors, or request context.
- Persisting any user-identifiable data.
- Implementing auth flows or “remember me”.

## Steps

### 1) Classify the data first

Treat as sensitive unless proven otherwise:

- secrets: tokens, API keys, credentials, session IDs
- PII: emails, phones, names, addresses, document numbers
- payloads: request/response bodies may contain secrets or PII

### 2) Apply OWASP baseline for sensitive features

For auth, storage, and network-heavy changes, validate decisions against:

- OWASP Mobile Top 10 (threat categories)
- OWASP MASVS/MAS checklist (implementation verification)

Document threat assumptions and chosen mitigations in PR notes or docs.

### 3) Store secrets only in flutter_secure_storage

Never store secrets in SharedPreferences, Drift, or plain files.

Use a wrapper interface so it is mockable:

```dart
abstract interface class ISecureStorage {
  Future<void> write({required String key, required String value});
  Future<String?> read({required String key});
  Future<void> delete({required String key});
}
```

Inject `ISecureStorage` via `DependenciesContainer` and use it in repositories/datasources.

### 4) Keep auth and storage testable

Test security behavior with fakes:

- fake secure storage (in-memory map)
- fake repositories/clients

Example fake:

```dart
final class InMemorySecureStorage implements ISecureStorage {
  final _store = <String, String>{};

  @override
  Future<void> write({required String key, required String value}) async {
    _store[key] = value;
  }

  @override
  Future<String?> read({required String key}) async => _store[key];

  @override
  Future<void> delete({required String key}) async {
    _store.remove(key);
  }
}
```

### 5) Prefer least-privilege data flow

- UI reads only what it needs (selectors/scopes).
- Avoid passing tokens through widget trees.
- Keep sensitive operations inside repositories/datasources.

### 6) Verify supply-chain and transport safety

- Screen new dependencies for maintenance and known vulnerabilities before adoption.
- Use HTTPS/TLS only for production traffic; never allow plaintext transport in release flows.

Overview

This skill provides concrete security and privacy guidance for AI agent projects that handle secrets, authentication, or any user-identifiable data. It focuses on classification, secure storage, testability, and transport safety to reduce risk and ensure consistent, auditable decisions. The recommendations are practical for Flutter/Dart agents and related infrastructure changes.

How this skill works

The skill inspects code paths that store or transmit sensitive data and prescribes controls: classify data first, apply OWASP baselines, and centralize secret storage using a secure storage interface. It enforces testable patterns with fakes for secure storage and recommends least-privilege data flows so UI layers never hold more than necessary. It also includes guidance for dependency and transport verification.

When to use it

When storing or reading tokens, API keys, session IDs, or credentials.
When logging user actions, errors, request context, or any PII.
When persisting user-identifiable data (emails, phones, addresses).
When implementing authentication flows, token refresh, or "remember me" features.
When adding new storage, network, or third-party dependencies that affect privacy.

Best practices

Classify data as secrets, PII, or payloads before changing storage or logs.
Use a secure storage abstraction (e.g., flutter_secure_storage) injected via a dependency container.
Keep auth/storage logic inside repositories/datasources; avoid passing tokens through UI/widget trees.
Provide fakes or in-memory secure storage for unit and integration tests to verify behavior.
Validate design and implementation against OWASP Mobile Top 10 and MASVS checklists.
Screen new dependencies for vulnerabilities and enforce HTTPS/TLS for production traffic.

Example use cases

Implementing token storage for an agent that calls external APIs: use injected secure storage and never write tokens to SharedPreferences.
Adding request logging: redact or omit PII and tokens, and document assumptions and mitigations in PR notes.
Building authentication flows: centralize refresh logic in a repository and test with in-memory secure storage.
Evaluating a new SDK: review maintenance, CVEs, and ensure transport uses TLS before adoption.
Refactoring UI: limit data selectors so views only read the fields needed, not raw tokens or full profiles.

FAQ

Can I store tokens in SharedPreferences during development?

Avoid it. Even in development, use the same secure storage abstraction or a test-only fake to prevent accidental leakage and make behavior consistent.

How do I verify I met OWASP recommendations?

Document threat assumptions, map features to OWASP/MASVS controls, and include verification notes in PRs or security docs; run dependency and static analysis scans.