GRACE security posture, in the open

Yes

GRACE supports MFA for all customer accounts and requires it at every production sign-in. After a correct password the user must pass a second factor before a session is issued. The default factor emails a 6-digit one-time code to the account email address; codes expire in 10 minutes and are stored only as SHA-256 hashes. Users may upgrade to an app-based TOTP authenticator (RFC 6238 — Google/Microsoft Authenticator, 1Password, Authy) by scanning a QR code; the TOTP secret is encrypted at rest with AES-256-GCM. MFA can also be scoped to specific roles by configuration.

Password policy and lockout implemented; SSO planned

Passwords are set through a complexity policy on create, change, and reset: minimum 8 characters with an uppercase letter, a lowercase letter, and a number (configurable via MIN_PASSWORD_LENGTH). Passwords are stored only as salted bcrypt hashes. Repeated failed sign-ins trigger temporary account lockout. Enterprise SSO (SAML/OIDC) is on the roadmap; until it ships, MFA-protected password authentication is the supported mechanism.

Minimum 8 characters requiring upper, lower, and numeric characters; configurable minimum length.

Enforced server-side on create/change/reset. Password fields are obscured in the UI. Reset and email-verification tokens are stored only as SHA-256 digests.

Yes

After a configurable number of failed attempts (default 10) the account is temporarily locked for a configurable window (default 15 minutes). The failed-attempt counter resets on successful authentication. The same lockout guards the MFA code-entry step against brute force.

Yes

GRACE enforces role-based access (sysadmin, administrator, charge nurse, viewer) with least-privilege defaults. All hospital data is scoped to the authenticated user's organization (tenant isolation); users cannot read another hospital's data.

Yes

Authenticated sessions expire after a configurable idle period (default 30 minutes in production) enforced in middleware, and have an absolute maximum lifetime. Session cookies are HTTP-only, SameSite=Lax, and Secure in production.

Scoped, hashed Bearer API keys per integration

Integrations authenticate with per-hospital Bearer keys (prefix grace_) that are stored only as SHA-256 hashes and carry least-privilege scopes (e.g. ingest:hl7, read:unit-state). Keys are minted and revoked by hospital admins.

Yes

Data is encrypted at rest at two layers: (1) application-layer field encryption using AES-256-GCM for sensitive fields such as authenticator (TOTP) secrets, keyed by a 256-bit data key (DATA_ENCRYPTION_KEY); and (2) full-volume/database encryption provided by the hosting tier. Passwords are stored only as salted bcrypt hashes; one-time codes and setup/reset tokens are stored only as SHA-256 digests.

Yes

All web and API traffic is served over HTTPS/TLS (1.2+). HSTS is enabled in production. Outbound webhooks are HMAC-SHA256 signed and delivered over HTTPS.

Yes

The AES-256 data key and session-signing secret are generated with a cryptographically secure RNG (see generate-secrets.sh), held only in the server environment file, and preserved across deployments so encrypted data remains readable. Keys are never committed to source control.

Yes

A system architecture and data-flow diagram is published on the Trust Center. It shows browser/EHR clients, the TLS boundary, network segmentation between the public marketing site and the authenticated application, the MongoDB data tier with encryption at rest, scoped API-key ingestion, and the external LLM inference boundary (de-identified inputs, no training).

In progress; pre-production scanning as a compensating control

Continuous dynamic application security testing (DAST) against the production surface is being implemented. In the interim, changes are scanned before release, dependencies are monitored for known vulnerabilities, and AI-assisted code review is applied in the SDLC as compensating controls.

Yes

Changes go through version control and review before release; secrets are kept out of source; releases are validated by build and type checking. AI-generated code is reviewed and validated against secure-coding standards before deployment.

Yes

Inbound API and ingestion payloads are validated and normalized; access controls and integrity constraints apply throughout the ingest pipeline.

Yes

Identifiers are passed in request bodies or as opaque IDs, not as confidential values in URLs. The evaluation tier does not process PHI.

Security response headers + clickjacking protection

Every response carries X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, a restrictive Referrer-Policy and Permissions-Policy, and (in production) HSTS with includeSubDomains and preload.

Yes — controls documented; AI free-text is opt-in and PHI-minimized

GRACE does not train foundation models; it uses a third-party LLM (Anthropic) under enterprise API terms that contractually prohibit training on GRACE inputs/outputs. OWASP LLM Top 10 mitigations include: prompt/output handling with structured context, redaction of digit strings before inference, least-privilege scoping of AI features, per-user opt-in for sending free text to the LLM, and a no-PHI evaluation tier. AI assists clinicians; it does not make automated significant decisions about individuals.

No

GRACE does not train or retrain models on customer data. The LLM provider is contractually prohibited from training on GRACE API inputs or outputs.

Yes

AI features are only reachable by authenticated, role-scoped users; requests are TLS-encrypted in transit; the evaluation tier is designed for non-PHI inputs.

In progress; monitoring and breach-notification process in place

Enterprise DLP tooling is being adopted. Compensating controls in place today: least-privilege access and tenant isolation, server-side request/ingestion logging for security and diagnostics, an immutable agreement-acceptance audit trail, and a documented incident-response and breach-notification process.

Within the United States

Application and database infrastructure for US customers is hosted within the United States.

Logically segregated

All records are scoped to a hospital tenant and access is enforced by the authenticated session's hospital identifier.

No

Non-production and demo environments use synthetic/de-identified data. The evaluation tier itself is contractually no-PHI.

Authentication events, API/ingestion events, and agreement acceptances

Logged detail includes success/failure, source, timestamp, event type, and the identity of the subject where applicable. Sign-in failures drive account lockout; agreement acceptances (user, timestamp, IP, user-agent, version) are retained in an immutable audit collection.

Operational and audit logs retained per policy

Agreement-acceptance audit records are retained for contract-formation defensibility. Operational/security logs are retained per the deployment's log-management configuration.

Planned; internal testing performed in the interim

A third-party penetration test is scheduled. In the meantime, internal security testing, dependency vulnerability monitoring, and pre-release scanning are performed. Pen-test results will be shared under NDA once complete.

Prioritized by severity with expedited handling of critical issues

Findings are identified, prioritized, patched, tested, and deployed through the change process; critical issues are expedited. Dependencies are updated in response to advisories.

Yes

Security issues can be reported to the Compliance & Security contact published on the compliance reference page.

Yes

Releases are version-controlled and deployed through a scripted, repeatable process with health checks; secrets (including the data-encryption key) are preserved across deploys and never rsync'd from developer machines.

Yes

Type checking and linting gate the build; dependencies are monitored for known vulnerabilities; AI-assisted review is applied to changes.

Yes — SOC 2 Type II report available under NDA

I AM GRACE INC. maintains SOC 2 Type II for the GRACE service, covering the Trust Services Criteria for Security, Availability, and Confidentiality. The report contains confidential control descriptions and is available to qualified customers and prospects under a mutual NDA.

SOC 2, HIPAA Security, NIST CSF; OWASP for application security

Controls are mapped to SOC 2 Trust Services Criteria, the HIPAA Security Rule, and NIST CSF; application security references the OWASP Top 10 and OWASP LLM Top 10.

Yes, when a BAA is executed for production PHI; evaluation tier is no-PHI

GRACE is HIPAA-ready. Where a hospital submits PHI to the Service, I AM GRACE INC. acts as a business associate under an executed Business Associate Agreement. Self-serve evaluation access is contractually restricted to non-PHI operational data; users attest to the no-PHI restriction at signup and at each agreement re-acceptance.

Yes

Material sub-processors are bound by written agreements restricting use of data to performing services for I AM GRACE; where PHI is in scope, sub-processors are subject to business-associate or equivalent protections. Product data inputs are de-identified/synthesized on the evaluation tier, and PII is minimized.

Yes

I AM GRACE INC. is a California corporation headquartered in the United States.

Evaluation tier: no PHI. Production tier: PHI only under a BAA. PII is minimized.

The evaluation tier operates without PHI. Account records contain minimal PII (name, work email). Production PHI processing requires an executed BAA.

Yes

Incident-response procedures detect, triage by severity, contain, and remediate security events, with defined escalation paths.

Yes

Where a breach of unsecured PHI occurs, I AM GRACE notifies the covered entity without unreasonable delay in accordance with the BAA and 45 CFR § 164.410, and complies with other applicable breach-notification laws.

Yes

Data is backed up and application releases are reproducible from version control and a scripted deploy, enabling recovery. Continuity and recovery procedures are maintained and reviewed.

Yes

Service health is monitored; the deployment is fronted by a reverse proxy with process supervision and automatic restart.