Security | Agily

Agily is a multi-tenant SaaS platform for project and work management. This page summarizes how we protect the data our customers entrust to us. For contractual detail, see the Data Processing Agreement; for the full list of providers, see the Sub-processors page.

Infrastructure

The Service runs on Amazon Web Services ([AWS region — to confirm]). The web frontend is served by [frontend host — e.g. Vercel].
Application services run as hardened, non-root container images built by our CI pipeline; images are scanned for known vulnerabilities before release.
Database schema changes are version-controlled, peer-reviewed, reversible, and applied through an automated pipeline.

Encryption

In transit: connections to the application use TLS (HTTPS), with HTTP Strict Transport Security.
At rest: passwords are stored only as bcrypt hashes; session, verification, and recovery tokens are stored only as SHA-256 hashes; designated sensitive fields — an organization’s stored AI provider key, connected chat/messaging provider tokens, webhook signing secrets, a connected Jira/Confluence API token, and two-factor (TOTP) secrets — are encrypted with AES-256-GCM. In progress: encryption at rest for the database volume and object storage.

Access control and tenant isolation

Role-based access control. Permissions are data-driven and enforced in the application’s service layer on every state-changing operation. Organization roles are customizable per tenant. A safeguard prevents a user from granting a permission they do not themselves hold.
Tenant isolation. Every project-scoped operation is authorized through a single access-resolution function that verifies organization membership and that the requested resource belongs to the caller’s organization; cross-tenant requests are rejected. Documentation content additionally supports per-document access control. In progress: database-level row isolation as a second layer, and an authorization test matrix across all endpoints.
Authentication. Email/password with bcrypt; optional single sign-on with Google or GitHub; time-based one-time-password (TOTP) multi-factor authentication with one-time backup codes; short-lived access tokens with rotating refresh tokens and refresh-token reuse detection; self-service management and remote revocation of active sessions and devices; immediate token revocation on sign-out and account deletion. In progress: organization-wide “require MFA” policy; account lockout after repeated failed sign-ins.
Internal access. Access to production systems and customer data by our personnel is limited to those who need it to operate and support the Service. In progress: documented periodic access reviews; joiner/mover/leaver process; least-privilege database role.

Logging and monitoring

Structured application logs with per-request correlation identifiers.
An append-only audit log of security- and configuration-relevant events, immutable at the database level, with automatic redaction of credential-like values.
Operational metrics are exposed for monitoring.
In progress: centralized log aggregation, error tracking, and alerting; an on-call process; an incident-response plan with breach-notification procedures.

Secure software development

All changes are peer-reviewed and go through automated checks in CI: static analysis and linting, unit and integration tests (including tests for tenant isolation and the privilege-escalation safeguard), dependency-vulnerability scanning, secret scanning, and container-image scanning.
Dependencies are monitored and updated on a regular cadence.
In progress: making security scans blocking; a documented secure-SDLC policy; threat modeling; an annual independent penetration test.

File uploads

Uploads go directly between the browser and object storage using short-lived signed URLs; file bytes do not pass through the application server on the primary path.
Every upload is validated against a file-type allow-list and a content-signature check against the actual bytes; a mismatch quarantines and deletes the file.
Uploaded files are scanned for malware; a file is never served before it has been scanned or explicitly marked as not-scanned.
Object keys are system-generated identifiers, never derived from a user-supplied filename. Every file operation is authorized per entity type.

Payments

Card data is entered on our payment processor’s hosted checkout and never reaches Agily’s servers. We store only an opaque processor token and a display hint (e.g. a card’s last four digits or a UPI handle).
Inbound payment webhooks are verified with an HMAC signature before they are processed.

Data protection and privacy

Export and deletion of account and membership data is available on request — not yet a self-service control in the interface. Account deletion anonymizes the user record and revokes sessions. Organization-level export and a scheduled, cancellable deletion flow (with a grace period) are available to organization administrators via the API today. In progress: exposing these same export/deletion controls in the interface; export/erasure coverage extended to all authored content; retention/purge schedules for logs, notifications, and other operational data.
Sub-processors are selected with data-protection diligence, bound by contract, and listed publicly with a change-notification mechanism.
See the Privacy Policy and DPA.

Availability and resilience

The Service has an automated deployment pipeline with a manual approval gate for production releases, and health-checked containers with automatic restart.
In progress: automated, encrypted, tested database backups with a documented recovery objective; a status page and uptime monitoring; a formal service-level agreement for enterprise customers.

Compliance posture

Agily is working toward SOC 2 and ISO 27001 readiness; formal audits will be pursued in line with customer demand.
The Service is not designed for regulated healthcare data (HIPAA) or for storing cardholder data (PCI DSS) — see the Acceptable Use Policy.
We can support GDPR / UK GDPR / India DPDP / CCPA obligations for customers as processor under our DPA.

Reporting a vulnerability (coordinated disclosure)

We welcome reports from security researchers.

Contact: security@agily.app (see also security.txt).
Please: give us reasonable time to investigate and fix before public disclosure; only test against your own account/organization; do not access, modify, or delete other users’ data; do not run denial-of-service tests, spam, or social-engineering attacks; and do not use automated scanners that generate abusive load.
We will: acknowledge your report, keep you updated, not pursue legal action for good-faith research that follows these rules, and credit you if you wish.

Security Overview