Security Overview
Qefro security is built around tenant isolation, workspace boundaries, least-privilege access, and auditable Business Actions. This section documents controls that exist in the running product on app.qefro.com / api.qefro.com — not aspirational marketing claims.
Use these pages for vendor questionnaires, internal security review, and production hardening. For Marketplace / SDK app builders, also read Solution security and Application security (SDK).
Short definition (citation-ready)
Qefro isolates each organization (tenant) and further scopes knowledge, tools, conversations, and Marketplace installs to AI Workspaces. Tool and SDK credentials are encrypted at rest; platform-to-app calls are HMAC-signed; HTTPS egress is SSRF-aware; optional end-user identity is forwarded rather than stored as a customer IdP; organization, identity, and tool execution events are logged.
Control map
Tenant isolation
Organizations cannot read each other’s knowledge, tools, people, or billing. Workspaces add a second boundary inside the tenant.
Authentication & access
User JWTs, widget tokens, RBAC, session revocation, and customer identity that stays with your Access Service.
Encryption
TLS in transit, AES-256-GCM for secrets at rest, bcrypt for org passwords, HS256 session JWTs.
Secrets
Where credentials live, what is publishable, and how to rotate without leaking keys into prompts or HTML.
Network & egress
HTTPS-only tool calls, SSRF / DNS pinning, webhook signatures, and CORS that never sends cookies to embeds.
Data handling
What Qefro stores, what stays in your ERP, PII masking limits, deletion, and LLM training posture.
Application & SDK security
HMAC v1 /qefro protocol, Marketplace Ed25519 packages, capability mediation, prompt-injection blast radius.
Audit logs
Org admin events, identity audit (no OTP/JWT), and Business Tool execution history.
Vulnerability disclosure
How to report a security issue to Qefro.
Compliance
Shipped controls vs roadmap. SOC 2, SSO, and hosting regions — confirm current status with Sales.
Architecture
Threats we design for
| Threat | Mitigation in Qefro |
|---|---|
| Org A reads Org B knowledge | Tenant-scoped APIs, indexes, storage, and connections |
| Public widget reads HR PDFs | Separate Customer vs Employee workspaces + channel binding |
| Chat triggers privileged refunds | Least-privilege tools; auth levels; no write tools on public workspaces by default |
| Tool URL hits cloud metadata | SSRF / DNS pinning; HTTPS only |
| Keys in browser or prompts | Server-side encrypted secrets; widget token is intentionally public |
| Forged platform → app calls | HMAC-SHA256 v1= over timestamp + raw body; skew window |
| Malicious Marketplace package | YAML/JSON/images only; Ed25519 signature; no arbitrary JS |
| Confused deputy | Identity forwarding (identify()); your API authorizes the end user |
| Unaudited model writes | Tool execution logs + org audit logs + identity audit |
| Stolen admin session | Session list/revoke; HttpOnly refresh cookie; RBAC |
Deeper agent threat model: AI Agent Security. Hardening checklist: Secure Business Actions.
Security review workflow
Run a security review before production
- Classify data — Which docs and tool responses are public vs internal vs regulated?
- Split workspaces — Customer Support vs HR/IT — never one mega-index.
- Lock RBAC — Owners/Admins configure; Members only see granted workspaces.
- Scope tools and apps — Read-only first; encrypt secrets; declare the fewest Marketplace capabilities.
- Prove with logs — Sample org audit, identity audit, and tool executions during pilot.
What is implemented vs roadmap
| Area | Status |
|---|---|
| Multi-tenant + workspace isolation | Implemented |
| Encrypted tool / SDK / channel credentials (AES-256-GCM) | Implemented |
HMAC-signed /qefro SDK protocol | Implemented |
| Marketplace package signing (Ed25519) + no arbitrary JS | Implemented |
| SSRF-aware tool / webhook egress with DNS pinning | Implemented |
Widget identify() identity forwarding | Implemented |
| Customer Access Service (org-owned OTP / login) | Implemented |
| Org audit logs + identity audit + tool logs | Implemented |
| Auth abuse rate limits | Implemented |
| Razorpay and Meta webhook signature verification | Implemented |
| Session list / revoke | Implemented |
| SOC 2 Type II | Roadmap — ask Sales for timeline |
| SSO / SAML for Admin Console | Roadmap — Enterprise discussions |
Practical API checks
# Organization audit trail (Admin/Owner JWT)
curl -sS -H "Authorization: Bearer $USER_JWT" \
https://api.qefro.com/api/v1/org/audit-logs
# Tool execution history for a Business Tool
curl -sS -H "Authorization: Bearer $USER_JWT" \
https://api.qefro.com/api/v1/tools/$TOOL_ID/logs
Best practices
- Separate staging and production organizations when feasible
- Prefer read-only Business Tools until citation quality is proven
- Re-review OpenAPI imports for overly broad write operations
- Treat uploaded documents as untrusted input when tools are enabled (prompt injection)
- Rotate SDK signing secrets and tool credentials on staffing changes
- Bind public channels only to customer-safe workspaces