Security without empty promises.

01 · OverviewSecurity 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.

02 · Security principlesSix principles guide Signaturesi security.

1. Minimum access

   Systems and people should receive only the access required for a defined purpose.

2. Secure defaults

   New accounts and features should begin with conservative access and privacy settings.

3. User isolation

   One user must not be able to access another user’s private account or application data.

4. Continuous visibility

   Important authentication, access and system events should be logged and monitored.

5. Limited exposure

   External providers should receive only the information necessary for a requested function.

6. Recovery readiness

   Security failures should trigger containment, investigation, recovery and user communication.

03 · Bean ID securityOne 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.

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.

04 · NEO securityAI 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.

NEO AI workspace Security model

1. Layer 01
   Account boundary

   Every conversation, file and memory item should be associated with the correct user.

2. Layer 02
   Retrieval boundary

   Memory retrieval should search only information the current account is authorized to access.

3. Layer 03
   Tool boundary

   Connected tools should receive only the minimum information needed for the current task.

4. Layer 04
   Action confirmation

   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.

05 · Bean securityCommunication 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.

Bean Communication Security areas

1. Messages

   Delivery and storage access should be limited to authorized conversation participants.

2. Media

   Files should use private storage paths, access checks and controlled download links.

3. Presence

   Online and last-active information should follow user-selected privacy settings.

4. Calls

   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.

06 · Encryption statusEncryption 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.

1. Intended
   Encryption in transit

   Supported production traffic should use secure HTTPS or equivalent encrypted transport.

2. Provider dependent
   Encryption at rest

   Database, storage and backup protection depends on the final infrastructure configuration.

3. Not verified
   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.

07 · Infrastructure securityConfiguration 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.

1. Database
   Row-level authorization

   Database policies should prevent cross-account reads, writes and unauthorized administrative access.

2. API
   Server-side validation

   Sensitive authorization must not rely only on checks performed in browser JavaScript.

3. Storage
   Private file access

   User files should not be exposed through permanent public URLs unless explicitly intended.

4. Secrets
   Protected credentials

   API keys, private tokens and service credentials must not be embedded in public frontend files.

5. Network
   Traffic protection

   Rate limiting, abuse detection and secure transport should protect public endpoints.

6. Backups
   Tested recovery

   Backups should follow defined retention, access and restoration procedures.

08 · Access controlEvery sensitive request must be authorized.

Authentication confirms who is making a request. Authorization determines what that person is allowed to access. Signaturesi requires both.

1. Step 01
   Authenticate

   Verify the account and active session.

2. Step 02
   Validate

   Confirm request structure and permitted values.

3. Step 03
   Authorize

   Confirm the account owns or may access the resource.

4. Step 04
   Record

   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.

09 · Data protectionCollect 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.

1. Collection
   Gather only required data

   Do not request device permissions or personal information without a clear feature requirement.

2. Separation
   Keep account data isolated

   User-owned information should remain separated through database and storage access rules.

3. Retention
   Define deletion periods

   Temporary files, logs and deleted account data should follow documented retention schedules.

4. Exposure
   Limit provider access

   External providers should receive only the data needed for a requested operation.

10 · Logging and monitoringSecurity events need useful visibility.

Signaturesi should record security-relevant events without placing private message or conversation content unnecessarily into logs.

Logs should themselves have restricted access and defined retention periods.

11 · Incident responseSecurity incidents require a defined process.

A security incident may include unauthorized access, leaked credentials, data exposure, malware, service abuse or a critical provider failure.

1. 01
   Detect

   Identify suspicious activity through reports, alerts or system monitoring.

2. 02
   Contain

   Revoke access, disable compromised credentials or isolate affected components.

3. 03
   Investigate

   Determine affected systems, data, accounts and the likely cause.

4. 04
   Recover

   Restore safe operation and verify that the vulnerability has been addressed.

5. 05
   Communicate

   Notify affected users or authorities when appropriate or legally required.

6. 06
   Improve

   Document the incident and prevent recurrence through technical and process changes.

View system status →

12 · Vulnerability reportingResponsible 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.

Signaturesi should publish a complete responsible disclosure policy before inviting external testing or offering a bug-bounty program.

13 · Current limitationsSecurity work remains incomplete.

Until development and independent review are complete, Signaturesi should clearly identify unresolved security areas rather than hiding them behind broad claims.

1. Unverified
   End-to-end encryption

   Full protection across messages, media, backups and calls has not been publicly verified.

2. Pending
   Independent penetration test

   No completed external security assessment is claimed on this page.

3. Pending
   Multi-factor authentication

   Availability depends on the final production account implementation.

4. Pending
   Formal security certifications

   Signaturesi does not currently claim formal security compliance certification.

5. Required
   Incident response testing

   Recovery and notification procedures should be tested before production launch.

14 · Security roadmapThe next security work should be measurable.

1. Phase 01
   Authentication hardening

   Secure login, session expiry, recovery, rate limiting and device management.

2. Phase 02
   Database isolation review

   Test row-level policies, storage permissions and backend authorization.

3. Phase 03
   Messaging security review

   Review message delivery, media access, call signaling and metadata handling.

4. Phase 04
   External penetration testing

   Engage qualified independent reviewers before making stronger public security claims.

5. Phase 05
   Incident-response exercise

   Test detection, containment, recovery and user communication procedures.

15 · User security responsibilitiesAccount 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.

16 · Security contactContact the Signaturesi security team.

Use a private and verified channel for vulnerability reports, account-security concerns or suspected incidents.

Signaturesi Security Vulnerabilities and incidents Draft contact

1. Security email
   security@signaturesi.com
2. General support
   support@signaturesi.com
3. Status page
   System status
4. Response target
   To be confirmed

These email addresses must be created, secured and actively monitored before this page is published.