Security & Trust

AMAlina is engineered with layered controls across authentication, authorization, transport security, and audit traceability. This page provides a simple view for founders and a deeper, technical view for engineers — without exposing sensitive internals.

FOUNDER VIEW Simple explanation

Security is the foundation — not a feature

AMAlina is built so that access decisions are enforceable, auditable, and defensible. In practical terms, it helps ensure people get only the access they need, and changes are controlled through clear policy-driven flows.

  • Encrypted communication (HTTPS/TLS) for UI and services
  • Server-side validation on every API request
  • Time-bound sessions (tokens expire automatically)
  • Audit visibility into access changes and policy outcomes
Share this section with non-technical stakeholders.
SECURITY & IT Structured assurance

Layered controls across identity, access, and audit

AMAlina applies defense-in-depth: authentication artifacts are time-bound, tokens are validated, and authorization is enforced server-side — not trusted from the browser.

  • Authentication: centralized IdP with short-lived exchange artifacts
  • Token security: signed JWTs with issuer/audience + expiry validation
  • Authorization: server-side permission checks per request
  • Audit: traceability for authentication events and access changes
Designed for enterprise governance expectations.
ENGINEER VIEW Detailed explanation

Security mechanics (high-level)

AMAlina uses signed JWT-based session control with server-side validation. Authentication exchange artifacts are short-lived, and API calls are authorized on each request. Sensitive secrets remain server-side.

  • Signed JWT sessions with strict validation (issuer / audience / expiry)
  • Session-scoped token storage (browser session context)
  • Server-side authorization checks per endpoint/method
  • Separation of concerns: IdP / SP responsibilities and REST enforcement
Note: This is intentionally public-safe. Deeper deployment hardening and threat-model details are shared under NDA.
Enough detail for engineers without exposing internals.
AUTHENTICATION SSO & login flow

Authentication & SSO

AMAlina supports centralized authentication through its IdP and can participate in SSO flows. Authentication occurs over TLS. Login exchange artifacts are time-bound to reduce exposure windows.

  • Encrypted transport (HTTPS/TLS)
  • Short-lived authentication exchange artifacts
  • Server-side token validation before session establishment
SESSION Token & expiry

Token & Session Safety

AMAlina sessions are time-bound. Tokens are validated server-side and expire automatically. Tokens may be stored in browser session storage (session-scoped context) to avoid long-lived persistence.

  • Signed JWTs with expiry validation
  • Issuer and audience validation
  • Session-scoped storage (non-persistent across full browser restarts)
AUTHORIZATION Server-side enforcement

Authorization Policy Enforcement

Authorization decisions are enforced server-side for every request. AMAlina does not rely on client-side checks to grant access. Policies and roles govern what a user can do.

  • Server-side validation for each API request
  • Method/endpoint access controls
  • Policy-aware controls (including SoD where configured)
WEB APP SECURITY Practical protections

Secure Engineering Practices

AMAlina is built with common web application security safeguards to reduce client-side and integration risks. Controls are applied at both the UI and API layers.

  • XSS-safe rendering: user-supplied content is treated as data and rendered safely (not executed as HTML/script).
  • API origin controls: cross-origin access can be restricted to approved front-end origins (CORS policy where applicable).
  • Password handling: passwords are stored using one-way hashing (not reversible encryption) and are never logged.
  • Secrets & tokens: signing keys and secrets remain server-side; tokens are validated server-side on every request.
  • Logging hygiene: sensitive values (passwords/tokens) are excluded from application logs by design.
Note: Detailed hardening guidance (headers, cipher settings, deployment recommendations) is available under NDA for security review.
PLATFORM Transport & deployment

Transport & Deployment Security

AMAlina supports on-prem deployments and single-tenant VPC patterns where customers control network boundaries, administrative access paths, and operational hardening.

  • HTTPS/TLS for UI and services
  • Network boundary control (on-prem or VPC)
  • Least-privilege connectivity model (recommended)
AUDIT Traceability

Audit & Traceability

AMAlina records security-relevant activity to support audits and investigations, including authentication events, access changes, and policy outcomes.

  • Authentication events
  • Access grants, revocations, and changes
  • Policy violations and outcomes
  • Administrative actions (where applicable)
ALIGNMENT Framework-ready language

Compliance Alignment

AMAlina is designed to support organizations aligning with common security and compliance frameworks (depending on overall deployment controls and processes).

  • ISO 27001 (alignment support)
  • SOC 2 (alignment support)
  • SOX (alignment support)
Important: We avoid claiming formal certification unless achieved. We position as “supports alignment” and provide evidence under NDA.
SECURITY REVIEW NDA details

Security Brief (Available Under NDA)

For enterprise security assessments, we can share deeper documentation under NDA, including deployment hardening guidance, operational controls, and implementation details appropriate for a security review.

SECURITY FAQ Common technical questions

Security Questions, Answered Clearly

Below are common questions raised during technical evaluations. Detailed security documentation is available under NDA where required.

Does AMAlina transmit customer data externally?

AMAlina operates within the customer-controlled environment. It does not export identity or access data to external services unless explicitly configured for approved integrations. There is no hidden telemetry or data sharing.

How does AMAlina protect against XSS?

User-supplied content is treated strictly as data and rendered safely. Authorization is enforced server-side on every request, ensuring access decisions cannot be altered from the browser.

How is cross-origin access handled?

API endpoints can restrict cross-origin requests to approved front-end origins. Authentication and authorization are validated server-side on every request.

How are passwords stored?

Passwords are stored using one-way hashing (not reversible encryption). Sensitive values are never logged.

How are tokens protected?

Tokens are time-bound, validated for issuer and audience, and verified server-side before any API execution. Session context is non-persistent and expires automatically.

Are sensitive details written to logs?

No. Application logging excludes passwords, secrets, and authentication tokens. Audit logs capture access events, not confidential credential data.

Note: Additional hardening recommendations (headers, deployment controls, environment isolation) are available during formal security review.