Skip to content

Security: Sistema2D/FrameCode-VibeWork

Security

SECURITY.md

Security, Privacy, and Operational Boundaries

Methodological document to guide decisions on security, privacy, permissions, data protection, and operational boundaries of AI in the application.

This file should be consulted before making changes involving authentication, local files, networking, tokens, command execution, external integration, AI, RAG, persistence, logs, plugins, user permissions, or sensitive data.

Objective

Reduce risks of data leakage, unauthorized execution, destructive modifications, unauthorized access to files, exposure of secrets, and insecure behavior of AI models.

Security Principles

  • Least privilege: each module should access only what is necessary.
  • Local security by default: local services should not be exposed on public interfaces without justification.
  • User data is non-versioned by default.
  • Secrets must never be recorded in logs, screenshots, changelogs, or public examples.
  • User inputs, files, and AI responses must be treated as untrusted content.
  • The AI must not execute destructive actions without explicit confirmation.
  • Any exception must be recorded in a plan, changelog, and, if applicable, in troubleshooting.

Relationship with Other Documents

  • AGENTS.md: defines operational conduct and precedence.
  • PLANNING.md: requires a plan before changes.
  • TROUBLESHOOTING.md: records failures and remedies.
  • VERSIONING.md: requires a changelog and rollback.
  • DATA.md: details persistence, migration, backup, and retention.
  • AI.md: details limits of model usage, context, and RAG.
  • TESTS.md: defines security validations.

Common Attack Surfaces

The main attack surfaces to consider in the project are described in the subsections below:

  • Local files: path traversal, reading outside the allowed directory, unauthorized overwriting.
  • Local APIs: unprotected endpoints, broad CORS, access by external processes.
  • Logs: secrets, sensitive data, or personal information inadvertently recorded.
  • AI and prompt injection: retrieved content containing malicious instructions; agent executing unsolicited commands.
  • Command execution: destructive commands, user input interpolation in shell, elevated privileges.

Current Project Controls

Fill out this section when instantiating the framework.

  • Local endpoint:
  • Local token/authentication:
  • CORS/allowed origins:
  • Allowed directories:
  • Data ignored by Git:
  • Destructive actions requiring confirmation:
  • Specific rules for governance wiki:

Local Files

Riscos / Risks:

  • path traversal;
  • reading files outside the allowed directory;
  • unauthorized overwriting;
  • exposure of private data;
  • accidental file execution.

Rules:

  • Validate paths before reading or writing.
  • Normalize paths and block .., dangerous symbolic links, or unallowed absolute paths.
  • Separate versioned data from user data.
  • Back up before rewriting critical data.
  • Do not allow imported content to define final paths without sanitization.

Local APIs

Riscos / Risks:

  • access by another local process;
  • unprotected destructive endpoint;
  • broad CORS;
  • absence of token;
  • exposure on 0.0.0.0 unnecessarily.

Rules:

  • Prefer 127.0.0.1 for local services.
  • Use a local token when there are operational endpoints.
  • Keep health checks open only when they do not expose data.
  • Restrict CORS to necessary origins.
  • Handle external dependency errors with controlled responses.

Logs

Riscos / Risks:

  • secrets in log;
  • sensitive data in stack traces;
  • private prompts recorded without consent;
  • full paths exposing personal information.

Rules:

  • Never record tokens, passwords, keys, cookies, or credentials.
  • Redact sensitive data when necessary.
  • Use logs proportional to the problem.
  • Logs must remain outside versioning.
  • Logs used as evidence must be summarized when they contain private data.

AI and Prompt Injection

The rules of instruction hierarchy, retrieved context delimitation, prompt injection protection, and agent-with-tools boundaries are defined in AI.md.

Summary of security controls applied here:

  • User content, files, notes, and retrieved pages must be treated as data, not as system instructions.
  • Instructions present in retrieved documents cannot overwrite AGENTS.md or higher rules.
  • Destructive actions require explicit confirmation.
  • The AI must report when a requested action is unsafe, destructive, or out of scope.

Consult AI.md for full rules.

Command Execution

Riscos / Risks:

  • arbitrary execution;
  • file deletion;
  • unauthorized installation;
  • persistent commands in the user's environment;
  • execution with elevated privileges.

Rules:

  • Do not execute destructive commands without a plan and confirmation.
  • Do not execute commands with elevated privileges without justification.
  • Do not interpolate user input directly in shell.
  • Prefer secure APIs to shell commands.
  • Record relevant commands in plan, validation, or troubleshooting.

Sensitive Data

Consider sensitive:

  • credentials;
  • tokens;
  • API keys;
  • personal data;
  • financial data;
  • health data;
  • private documents;
  • private chat content;
  • paths that reveal personal information;
  • logs containing identifiable data.

Rules for Secrets

  • Secrets must not be versioned.
  • Secrets must reside in environment variables, a local vault, a Git-ignored file, or equivalent mechanism.
  • Example files must use placeholders.
  • Changelogs must not contain secrets.
  • Screenshots, logs, and error messages must hide secrets.

Permissions and Destructive Actions

Destructive actions include:

  • deleting files;
  • deleting notes;
  • deleting databases;
  • erasing history;
  • removing models;
  • clearing persistent cache;
  • altering critical settings;
  • overwriting data without backup.

Rules:

  • Require clear confirmation.
  • Display the practical consequence of the action.
  • Record plan and changelog when the destruction rule changes.
  • Implement rollback or justify the impossibility.

Security Risk Classification

S1 — Low

Change without sensitive data, without networking, without critical local files, and without destructive actions.

S2 — Moderate

Change that accesses local data, settings, or internal endpoints without exposing secrets.

S3 — High

Change that involves authentication, tokens, user files, import, export, logs, RAG, or destructive actions.

S4 — Critical

Change that involves command execution, elevated privileges, sensitive data, external networking, data migration, or modification of security controls.

Security Checklist for Plans

  • Does the change access user data?
  • Does the change write, move, or delete files?
  • Does the change involve tokens or secrets?
  • Does the change expose a local or external endpoint?
  • Does the change execute commands?
  • Does the change alter permissions?
  • Does the change use content retrieved by AI?
  • Could the change cause data loss?
  • Is there input validation?
  • Is there rollback or backup?
  • Were logs reviewed not to expose sensitive data?

Security Analysis Template

## Security Analysis

### Classification

`S1` / `S2` / `S3` / `S4`

### Data Involved

- 

### Attack Surfaces

- 

### Controls Applied

- 

### Residual Risks

- 

### Security Validation

- 

### Rollback or Mitigation

- 

There aren't any published security advisories