docs/security-assessment.md

ARF Security Self‑Assessment & Penetration Test Report

Version: 1.0
ARF Version: v4.3.2
Date: July 9, 2026
Classification: Proprietary – Access‑Controlled
Scope: arf-api, arf-gateway, agentic_reliability_framework

---

1. Executive Summary

This document presents the results of a structured security review of the ARF platform, conducted by the development team and supplemented by manual penetration testing performed by the steward. It is organized according to the OWASP Top 10 (2021) and includes specific findings, code references, and a risk‑based prioritization of residual gaps. The Bayesian confidence model introduced in Section 7 quantifies our degree of belief that the platform is secure enough for a regulated pilot deployment.

1.1 Overall Risk Rating

Category	Rating	Explanation
Confidentiality	Medium	Internal API key protects governance endpoints; no encryption at rest for audit logs.
Integrity	High	Ed25519 signatures, hash‑chained audit logs, and constant‑time key comparison prevent tampering.
Availability	High	Kubernetes HPA, liveness/readiness probes, and rolling updates ensure resilience.
Authentication	High	Gateway uses salted SHA‑256 API keys; internal API key prevents direct API access.
Authorization	Medium	API key tiers exist but are not granularly enforced at the endpoint level.

---

2. Scope

The security review covered the following components:

Component	Language	Lines of Code	Reviewed
arf-api (FastAPI)	Python	~1,700	Yes
arf-gateway (Go)	Go	~500	Yes
agentic_reliability_framework	Python	~15,000	Partial (core governance only)
enterprise/arf_execution (Rust)	Rust	~1,200	Partial (gates only)

Out of scope: Third‑party dependencies not directly audited; infrastructure‑level security (AWS IAM, Kubernetes RBAC); physical security.

---

3. OWASP Top 10 (2021) Assessment

3.1 Broken Access Control (A01)

Finding: The API routes previously had no authentication. This has been remediated in v4.3.2 by adding the verify_internal_key dependency to the governance router (routes_governance.py). The gateway proxies requests and injects the X‑Internal‑Key header. The API key is compared using a constant‑time algorithm to prevent timing attacks.

Code evidence: app/api/deps.py (verify_internal_key), app/api/routes_governance.py (router dependency).

Residual risk: Low. If the ARF_INTERNAL_API_KEY environment variable is not set, the dependency is a no‑op (for local development). This must be enforced in production via Kubernetes Secrets.

3.2 Cryptographic Failures (A02)

Finding: No cryptographic failures detected. The gateway uses salted SHA‑256 for API key storage (auth/apikey.go). HealingIntent supports Ed25519 signatures (healing_intent.py). Context hashes use SHA‑256. Audit logs are hash‑chained.

Code evidence: internal/auth/apikey.go, healing_intent.py (sign/verify), governance_loop.py (context_hash).

Residual risk: Low. No known weaknesses in the employed algorithms.

3.3 Injection (A03)

Finding: The API uses Pydantic models with strict field validation (BaseIntentRequest), which mitigates type‑based injection. The gateway and API do not construct SQL queries with user input directly (the risk engine uses parameterized queries via SQLAlchemy; the gateway uses SQLite with placeholders). No injection vulnerabilities were found.

Code evidence: models/infrastructure_intents.py (validators), usage_tracker.py (parameterized queries), auth/apikey.go (placeholders).

Residual risk: Low.

3.4 Insecure Design (A04)

Finding: No design‑level flaws identified. The separation of advisory and execution layers, the immutable HealingIntent contract, and the deterministic governance loop are strong design patterns that reduce the attack surface.

Residual risk: Low.

3.5 Security Misconfiguration (A05)

Finding: CORS is restricted to a specific frontend origin in main.py. The Kubernetes NetworkPolicy restricts API access to the gateway pod only. However, the gateway’s rate‑limiter (token bucket) is configured with a global rate of 100 req/min and burst of 20 – this may be too permissive for some tiers.

Code evidence: app/main.py (CORS), deploy/kubernetes/arf-api/networkpolicy.yaml, internal/middleware/ratelimit.go.

Residual risk: Medium. Rate limiting should be tier‑specific.

3.6 Vulnerable and Outdated Components (A06)

Finding: Dependencies are tracked via requirements.txt and go.mod. No automated vulnerability scanning is integrated into CI. A manual review of the Go dependencies (go.sum) shows up‑to‑date packages; Python dependencies were not exhaustively audited.

Code evidence: requirements.txt, go.mod, go.sum.

Residual risk: Medium. Recommend integrating pip‑audit and govulncheck into CI.

3.7 Identification and Authentication Failures (A07)

Finding: The gateway implements salted SHA‑256 API key hashing with random 16‑byte salts (auth/apikey.go). The API’s internal key uses constant‑time comparison. No authentication bypasses were found during testing.

Code evidence: auth/apikey.go, deps.py (_constant_time_compare).

Residual risk: Low.

3.8 Software and Data Integrity Failures (A08)

Finding: The HealingIntent supports Ed25519 signatures, and audit logs are hash‑chained. This provides strong integrity guarantees. However, there is no mechanism to verify the integrity of the governance loop’s Python dependencies at runtime.

Residual risk: Medium. Consider adding a signed SBOM or integrity check for dependencies.

3.9 Security Logging and Monitoring Failures (A09)

Finding: The gateway uses structured logging (slog) with JSON output to stdout. The API uses OpenTelemetry tracing and Prometheus metrics. Audit logs are written to PostgreSQL. However, there is no centralized log aggregation or alerting configured.

Residual risk: Medium. Recommend integrating a log aggregation system (e.g., Loki, CloudWatch) and alerting on security events (e.g., repeated 401 responses).

3.10 Server‑Side Request Forgery (SSRF) (A10)

Finding: The gateway proxies requests to the core API URL specified by the ARF_CORE_URL environment variable. If an attacker could manipulate this variable, they could redirect internal traffic. However, the variable is set at deployment time and cannot be modified via user input.

Residual risk: Low.

---

4. Additional Security Controls

4.1 Internal API Key Protection (v4.3.2)

The governance endpoints are now protected by an internal API key (X‑Internal‑Key header), verified via constant‑time comparison. This ensures that even if an attacker bypasses the gateway, the API itself is not open. The gateway injects this header for all authenticated requests.

4.2 Rate Limiting

The gateway implements a per‑API‑key token‑bucket rate limiter (internal/middleware/ratelimit.go). The default configuration (100 req/min, burst 20) is conservative but may need to be adjusted per tier in production.

4.3 Network Segmentation

The Kubernetes NetworkPolicy (deploy/kubernetes/arf-api/networkpolicy.yaml) restricts ingress to the API pods to only traffic from pods labeled app: arf-gateway. This provides defense‑in‑depth beyond the internal API key.

---

5. Penetration Test Findings (Steward‑Reported)

The steward performed manual penetration testing and reported the following:

Finding	Severity	Status
No authentication on governance endpoints (direct API access)	Critical	Fixed (v4.3.2, internal key)
CORS restricted to single origin	Informational	Accepted
Rate limiter bypassable via multiple API keys	Medium	Open (recommend per‑tier limits)
No brute‑force protection on API key validation	Medium	Open (gateway does not track failed attempts)

---

6. Residual Risk Matrix

Risk	Likelihood	Impact	Rating	Mitigation
Tier‑agnostic rate limiting	Medium	Low	Low	Implement per‑tier rate limits in gateway.
No brute‑force protection	Low	Medium	Low	Add exponential backoff or account lockout after N failed attempts.
Dependency vulnerabilities (unscanned)	Medium	Medium	Medium	Integrate automated scanning into CI.
No centralized log aggregation	High	Low	Medium	Add Loki or CloudWatch log shipping.
Internal key not enforced in dev mode	Low	High	Low	Ensure production Helm chart requires the key.

---

7. Bayesian Confidence Model

We model the platform's security readiness as a Beta distribution over the probability that no critical security vulnerability exists. We start with a weak Beta(1,1) prior and update based on the findings from this assessment.

• Positive evidence (α‑1): API auth fixed, constant‑time key compare, Ed25519 signatures, hash‑chained logs, salted API key hashing, NetworkPolicy, CORS restriction, rate limiter.
• Negative evidence (β‑1): No brute‑force protection, dependency scanning not integrated, no centralized log alerting, rate limiter not tier‑specific.

Posterior: Beta(9, 5). Posterior mean: 0.64. This represents our current degree of belief that the platform is secure enough for a pilot. The remaining open items would shift this toward Beta(12,5) with mean ~0.71.

---

8. Recommendations

Priority	Recommendation	Effort	Impact
P0	Add brute‑force protection to gateway auth (account lockout after 5 failed attempts).	Small	High
P0	Implement per‑tier rate limiting in the gateway.	Medium	Medium
P1	Integrate pip‑audit and govulncheck into CI.	Small	Medium
P1	Add centralized log aggregation (Loki or CloudWatch).	Medium	Medium
P2	Produce a signed SBOM for the governance loop dependencies.	Small	Low

---

9. Conclusion

ARF’s security posture is adequate for a controlled pilot deployment in a regulated environment, provided the P0 recommendations are addressed before production. The platform demonstrates strong integrity controls (Ed25519, hash chains) and authentication (salted SHA‑256, internal key). The residual risks are mitigable with relatively low effort.

This document is proprietary and access‑controlled. Distribution is limited to qualified pilots and enterprise customers under written agreement.