Sentinel-IAM Warden

Sentinel-IAM is an AI-powered Identity and Access Management (IAM) agent. It evaluates high-stakes access requests against a strict security policy by combining LLM reasoning with real-time system tool execution.

The Problem

Traditional RBAC (Role-Based Access Control) is static. In emergency scenarios (P0 incidents), developers often need "Break Glass" access that isn't granted by default. Sentinel-IAM automates this by validating the context of a request against live incident data.

Architecture

• Language Model: OpenAI GPT-4o / GPT-4o-mini
• Runtime: Ruby 3.3 (WSL2/Ubuntu)
• Policy Engine: Structured YAML-to-JSON schema injection.
• Guardrails: Two-pass "Guardian" system for Prompt Injection defense.
• Observability: Sinatra-based Web Dashboard and persistent Audit Logging.

Logic Flow: Structured Policy Evaluation

1. Guardian Scan: A low-cost model (GPT-4o-mini) scans the input for malicious intent or system overrides.
2. Schema Evaluation: The Warden loads policy.yml, a structured "Policy-as-Code" source of truth.
3. Verification:
   • IncidentReporter: Checks for active P0/High-severity tickets.
   • TrainingValidator: Verifies user certification status via dynamic lookup.
4. Synthesis: The AI cross-references tool results against the YAML requirements.
5. Verdict: Final GRANT (with dynamic token) or DENY is issued.

Setup

1. Environment: Ensure you are running WSL2 (Ubuntu).
2. Installation:

   bundle install

3. Configuration: Create a .env file with your OPENAI_API_KEY
4. Policy: Edit policy.yml to define your organizational rules.

Usage Examples

Scenario: Authorized Access (All conditions met)

./bin/warden "I am a Senior Dev named 'John Doe'. I need production access for a P0 database fix."
# Result: GRANT

Scenario: Safety Violation (User not certified)

./bin/warden "I am a Senior Dev named 'Alice'. I need production access for a P0 fix."
# Result: DENY (Reason: Alice lacks Production Safety Training)

Security & Audit

All decisions are derived from a "Source of Truth" policy file. The agent cannot grant access that violates the core constraints defined in policy.yml, even if the LLM is prompted to bypass them. Logging was implemented and file audit.log contains all interactions with timestamps.

Security Principles

1. Least Privilege: Access is denied by default unless both incident and training factors return positive results.
2. Traceability: The audit.log provides a forensic timeline for compliance reviews.
3. Immutability: The core security policy is externalized from the AI prompt to prevent state-drift.
4. Anomaly Detection: Pre-flight "Guardian" check identifies and blocks Prompt Injection and System Override attempts before they reach the decision engine.

Project Structure

.
├── bin/
│   ├── warden                # CLI Entry point
│   └── dashboard             # Web UI (Sinatra)
├── lib/sentinel_iam.rb       # Core Orchestrator & Guardrails
├── lib/sentinel_iam/tools/   # Executable security tools
├── spec/warden_spec.rb       # Automated test suite
├── policy.yml                # Structured "Policy-as-Code"
├── audit.log                 # Forensic decision trail
└── Gemfile                   # Dependencies

Testing & Reliability

To ensure the security policy is "unbreakable", we use an automated RSpec suite. This prevents regression and ensures the AI consistently enforces rules for different roles.

Run the test suite:

bundle exec rspec

Observability Dashboard

The system includes a lightweight administrative UI to monitor access requests in real-time. It highlights grants, denials, and security anomalies for forensic review.

To launch the dashboard:

./bin/dashboard

---

License

This project is solely for educational purposes.