- What is Brain for Laravel?
- Brain is an AI agent framework for Laravel that lets you build LLM-powered agents with tools, memory, and multi-step workflows using simple PHP classes. It connects agents to your app's data, services, and existing Laravel features. It is positioned as a process-driven architecture alternative for Laravel applications.
- How do I install r2luna/brain in a Laravel app?
- Install it with Composer using composer require r2luna/brain. Then follow the README and documentation for configuration, including running brain:migrate where required and setting up any environment values. Ensure APP_KEY is configured because sensitive queued payloads are encrypted with it.
- Which Laravel versions does Brain support?
- The provided context does not list specific Laravel or PHP version constraints for Brain. Check the package's composer.json and README for the supported framework versions before installing. Composer will also enforce the declared constraints during installation.
- How does Brain handle sensitive data with the #[Sensitive] attribute?
- Declaring a value as #[Sensitive] redacts it across workflow events, validation errors, nested workflows, exception messages, console output, previews, result tables, run history, and VarDumper dumps. In the security-hardening release, redaction keys apply workflow-wide and nested workflows inherit their parent's keys. Sensitive values in queued payloads are also encrypted with APP_KEY.
- Are sensitive values encrypted in the Brain queue?
- Yes, in the 4.1.4 security-hardening release, #[Sensitive] values are encrypted with APP_KEY at queue time. This moves Brain from redacting at display edges to protecting sensitive payloads at rest in the queue. It also introduces a hard dependency on proper key management.
- What happens if I rotate APP_KEY after upgrading Brain?
- Queued sensitive payloads encrypted with the old key must remain decryptable, so keep the old key in APP_PREVIOUS_KEYS until all jobs queued under it are processed. Without that, jobs can fail at processing time when Brain tries to decrypt the payload. Teams with scheduled or automated key rotation should update their runbook before upgrading.
- Can I upgrade to Brain 4.1.4 without draining the queue?
- Yes, the release is additive for consumers. Jobs queued before 4.1.4 still run, and SensitiveValue payloads queued before encryption remain readable. The main mandatory operational step is confirming your key-rotation setup supports APP_PREVIOUS_KEYS.
- Does Brain validate #[Sensitive] values against real values or redacted placeholders?
- In the security-hardening release, rules() validates the decrypted real value rather than a redacted placeholder. This is the correct behavior, but it can surface previously passing payloads as failing and can change the shape of validation errors. Review your validation rules if you rely on sensitive fields.
- How does redaction scope work across nested workflows in Brain?
- Redaction keys now apply workflow-wide rather than per action, and nested workflows inherit their parent's keys. This is a stricter PII and credential boundary, but it can change what appears in dashboards, run histories, and support workflows. Teams that relied on seeing a value in a non-sensitive action's output may lose that visibility.
- What should I do about logs created by older Brain versions that leaked sensitive values?
- Upgrading stops new leaks but does not remediate existing artifacts in log aggregators, exception trackers such as Sentry or Bugsnag, or brain:run history. Perform a log-hygiene review and consider purging or rotating any credentials that were exposed. The context does not state whether pre-4.1.4 versions should be treated as compromised, so assess based on your exposure.