Security should be designed into the product.
Signaturesi is building connected services for intelligence, communication and unified identity. These services may process account information, conversations, messages, files and personal settings.
Security therefore cannot be treated as a visual feature or marketing label. It requires secure authentication, strict access rules, careful data handling, reliable monitoring and a documented response process.
Six principles guide Signaturesi security.
Minimum access
Systems and people should receive only the access required for a defined purpose.
Secure defaults
New accounts and features should begin with conservative access and privacy settings.
User isolation
One user must not be able to access another user’s private account or application data.
Continuous visibility
Important authentication, access and system events should be logged and monitored.
Limited exposure
External providers should receive only the information necessary for a requested function.
Recovery readiness
Security failures should trigger containment, investigation, recovery and user communication.
One identity requires strong account protection.
Bean ID connects access across Signaturesi products. A compromised Bean ID could affect NEO, Bean and related account data, making authentication security a critical requirement.
Passwords should be stored using a trusted password-hashing system, never as readable text.
Sessions should expire, rotate appropriately and support revocation after suspicious activity.
Login, signup and recovery endpoints should resist automated guessing and abusive requests.
Recovery should verify account ownership without exposing secrets or enabling easy takeover.
Users should be able to review and remove active authenticated devices or sessions.
Important login, recovery and account-change events should generate clear alerts.
Multi-factor authentication
Multi-factor authentication is a recommended production requirement. It should not be described as available until the complete enrollment, recovery and backup-code flows have been implemented.
AI systems need isolation between users, memories and tools.
NEO may process prompts, generated responses, uploaded files, project information and personal memory. Security controls must prevent unauthorized users, tools and services from accessing unrelated information.
Every conversation, file and memory item should be associated with the correct user.
Memory retrieval should search only information the current account is authorized to access.
Connected tools should receive only the minimum information needed for the current task.
Sensitive external actions should require explicit user confirmation.
Prompt injection and untrusted content
Uploaded files, websites and retrieved content may contain instructions intended to manipulate an AI system. NEO should treat external content as untrusted data and should not automatically allow it to override system permissions or user intent.
Memory integrity
Durable memory should not be created silently from every conversation. Users should be able to inspect, correct and delete saved memory, and sensitive data should be excluded or restricted by default.
Communication security covers more than message content.
Bean may process message content, attachments, presence information, delivery records and call connection data. Each part requires its own access, retention and security controls.
Delivery and storage access should be limited to authorized conversation participants.
Files should use private storage paths, access checks and controlled download links.
Online and last-active information should follow user-selected privacy settings.
Signaling, permissions and connection metadata should be protected from unauthorized access.
Abuse prevention
Bean should include controls for blocking, reporting, spam reduction, suspicious account detection and rate limiting without exposing private conversations more broadly than necessary.
Encryption claims must match the real implementation.
Signaturesi intends to protect data during supported network transmission and to use appropriate storage protections through its infrastructure providers.
Encryption in transit
Supported production traffic should use secure HTTPS or equivalent encrypted transport.
Encryption at rest
Database, storage and backup protection depends on the final infrastructure configuration.
End-to-end encryption
Bean must not claim end-to-end encryption until message, media, backup and call protection has been fully implemented and independently reviewed.
Configuration matters as much as provider selection.
Signaturesi may rely on external hosting, database, network, communication and AI providers. Using a reputable provider does not automatically make an application secure.
Database policies should prevent cross-account reads, writes and unauthorized administrative access.
Sensitive authorization must not rely only on checks performed in browser JavaScript.
User files should not be exposed through permanent public URLs unless explicitly intended.
API keys, private tokens and service credentials must not be embedded in public frontend files.
Rate limiting, abuse detection and secure transport should protect public endpoints.
Backups should follow defined retention, access and restoration procedures.
Secret API keys, database service-role keys and administrative credentials must remain in secure server-side environments.
Every sensitive request must be authorized.
Authentication confirms who is making a request. Authorization determines what that person is allowed to access. Signaturesi requires both.
Verify the account and active session.
Confirm request structure and permitted values.
Confirm the account owns or may access the resource.
Log important events for security investigation.
Hidden buttons, inaccessible interface elements or private-looking URLs are not security controls. Authorization must be enforced by the backend.
Collect less, retain less and expose less.
Reducing unnecessary data can reduce security risk. Signaturesi should limit collection and retention to what is required for product functionality, security and legal obligations.
Do not request device permissions or personal information without a clear feature requirement.
User-owned information should remain separated through database and storage access rules.
Temporary files, logs and deleted account data should follow documented retention schedules.
External providers should receive only the data needed for a requested operation.
Security events need useful visibility.
Signaturesi should record security-relevant events without placing private message or conversation content unnecessarily into logs.
| Event | Why it matters | Recommended response |
|---|---|---|
| Repeated failed login | Possible credential guessing | Rate limit and review |
| New recovery request | Possible account takeover attempt | Notify account owner |
| Unusual data access | Possible authorization failure | Block and investigate |
| Elevated error rate | Possible outage or attack | Trigger operational alert |
| Administrative action | High-impact internal access | Record actor and reason |
Logs should themselves have restricted access and defined retention periods.
Security incidents require a defined process.
A security incident may include unauthorized access, leaked credentials, data exposure, malware, service abuse or a critical provider failure.
Identify suspicious activity through reports, alerts or system monitoring.
Revoke access, disable compromised credentials or isolate affected components.
Determine affected systems, data, accounts and the likely cause.
Restore safe operation and verify that the vulnerability has been addressed.
Notify affected users or authorities when appropriate or legally required.
Document the incident and prevent recurrence through technical and process changes.
Responsible security research is welcome.
Security researchers who believe they have discovered a vulnerability should report it privately and allow reasonable time for investigation and remediation.
- A clear description of the vulnerability.
- The affected page, endpoint or product.
- Reproduction steps or a safe proof of concept.
- The possible security impact.
- A contact method for follow-up.
- Access or download other users’ private data.
- Disrupt production services or availability.
- Use social engineering against users or staff.
- Deploy malware or destructive payloads.
- Publicly disclose an unresolved vulnerability.
Report a vulnerability privately.
Replace this address with a verified and actively monitored security inbox before launch.
Signaturesi should publish a complete responsible disclosure policy before inviting external testing or offering a bug-bounty program.
Security work remains incomplete.
Until development and independent review are complete, Signaturesi should clearly identify unresolved security areas rather than hiding them behind broad claims.
Full protection across messages, media, backups and calls has not been publicly verified.
No completed external security assessment is claimed on this page.
Availability depends on the final production account implementation.
Signaturesi does not currently claim formal security compliance certification.
Recovery and notification procedures should be tested before production launch.
The next security work should be measurable.
Secure login, session expiry, recovery, rate limiting and device management.
Test row-level policies, storage permissions and backend authorization.
Review message delivery, media access, call signaling and metadata handling.
Engage qualified independent reviewers before making stronger public security claims.
Test detection, containment, recovery and user communication procedures.
Account security also depends on user behavior.
Users should take reasonable steps to protect their Signaturesi accounts and devices.
- Use a strong password that is not reused on another service.
- Keep account recovery methods accurate and protected.
- Do not share passwords, login codes or recovery links.
- Sign out from devices you no longer control.
- Review unexpected login or account-change notifications.
- Keep browsers, operating systems and devices updated.
- Report suspected account compromise immediately.
Signaturesi will never need a user’s password through an ordinary support message.
Contact the Signaturesi security team.
Use a private and verified channel for vulnerability reports, account-security concerns or suspected incidents.
These email addresses must be created, secured and actively monitored before this page is published.