Spaces:
Configuration error
Configuration error
Niranjan-Murugarasu024
feat: TradeSense AI Chairman Edition production release ready for Hugging Face Spaces
0125724 |
Download docs/security/ACCESS_CONTROL_MATRIX.md from BlueMen/tradesenseAi: direct link, hf CLI and curl.
- Browser
- Download file 4.12 kB
-
https://huggingface.co/spaces/BlueMen/tradesenseAi/resolve/main/docs/security/ACCESS_CONTROL_MATRIX.md
- Command line
-
hf download hf://spaces/BlueMen/tradesenseAi/docs/security/ACCESS_CONTROL_MATRIX.md
-
curl -L -o ACCESS_CONTROL_MATRIX.md https://huggingface.co/spaces/BlueMen/tradesenseAi/resolve/main/docs/security/ACCESS_CONTROL_MATRIX.md
4.12 kB
TradeSense AI — Module 08: Institutional Access Control Matrix & Segregation of Duties
Document Reference: TS-SEC-ACM-08
Classification: Institutional Internal / Highly Confidential
Standard Compliance: SOC 2 Type II (Common Criteria CC6.1 - CC6.3), ISO/IEC 27001 Annex A.9
1. Role-Based Access Control (RBAC) Matrix
TradeSense AI enforces strict, least-privilege role-based access control. The table below outlines the institutional permissions assigned to each defined role:
| Permission Identifier | Description | VIEWER | RESEARCHER | REVIEWER | RISK_REVIEWER | OPERATOR | AUDITOR | ADMIN |
|---|---|---|---|---|---|---|---|---|
RESEARCH_READ |
View backtests, features & model specs | [x] | [x] | [x] | [x] | [x] | [x] | [x] |
RESEARCH_CREATE |
Create hypotheses, backtests & strategies | [ ] | [x] | [ ] | [ ] | [ ] | [ ] | [x] |
RESEARCH_EXECUTE |
Dispatch compute jobs & run pipelines | [ ] | [x] | [ ] | [ ] | [x] | [ ] | [x] |
RESEARCH_APPROVE |
Review and approve strategy deployment | [ ] | [ ] | [x] | [x] | [ ] | [ ] | [x] |
RESEARCH_ARCHIVE |
Archive and deprecate trading strategies | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [x] |
DATASET_READ |
Query market data tables and datasets | [x] | [x] | [x] | [x] | [x] | [x] | [x] |
DATASET_INGEST |
Ingest external vendor feeds or files | [ ] | [ ] | [ ] | [ ] | [x] | [ ] | [x] |
DATASET_DELETE |
Purge raw or transformed data | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [x] |
GOVERNANCE_READ |
View pre-registrations & approval logs | [x] | [x] | [x] | [x] | [x] | [x] | [x] |
GOVERNANCE_MANAGE |
Register governance policies & gates | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [x] |
GOVERNANCE_OVERRIDE |
Emergency governance exception override | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [x] |
AUDIT_READ |
Read immutable hash chains & ledger proofs | [ ] | [ ] | [ ] | [x] | [x] | [x] | [x] |
AUDIT_EXPORT |
Export cryptographically sealed bundles | [ ] | [ ] | [ ] | [ ] | [ ] | [x] | [x] |
AUDIT_VERIFY |
Re-verify Merkle proofs & HMAC chains | [ ] | [ ] | [ ] | [ ] | [ ] | [x] | [x] |
SYSTEM_CONFIG_READ |
Inspect non-sensitive system settings | [ ] | [ ] | [ ] | [ ] | [x] | [x] | [x] |
SYSTEM_CONFIG_WRITE |
Modify system configurations & keys | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [x] |
2. Segregation of Duties (SoD) & Maker-Checker Policies
To mitigate internal fraud, collusion, and unauthorized production algorithmic changes, the platform implements programmatic Segregation of Duties policies:
| Policy ID | Operation | Restrictive Rule | Enforcement Mechanism |
|---|---|---|---|
| SOD-01 | Production Strategy Promotion | Author cannot review or approve own strategy (maker_id != checker_id). |
SecurityPolicyEngine.evaluate_governance_action() raises HTTP 403 if action.maker_id == context.user_id. |
| SOD-02 | Risk Threshold Override | Researcher cannot grant risk exception (RISK_REVIEWER or ADMIN required). |
Explicit role validation; RESEARCHER role does not carry GOVERNANCE_OVERRIDE. |
| SOD-03 | Audit Ledger Sealing | Author of ledger evidence cannot verify or certify audit records. | AUDITOR role separation; independent cryptographic key used for ledger verification. |
| SOD-04 | Market Data Ingestion vs Validation | Data ingestion operators cannot approve backtest results using those datasets. | OPERATOR cannot possess RESEARCH_APPROVE permission. |
3. Server-Authoritative Identity Enforcement Rules
- Client Identity Stripping: Any inbound JSON payload containing
user_id,actor_id,role,status, ortenant_idis sanitized bySecurityPolicyEngine.sanitize_client_payload(). - Context Binding: Authorized parameters are solely populated from the validated JWT claims (
TokenPayload.sub,TokenPayload.role,TokenPayload.tenant_id). - Database Tenant Context: Every active transaction binds the verified
tenant_idinto the Postgres session viaSET LOCAL app.current_tenant_id = :tenant_id, triggering Row Level Security policies.