AeglysAI

Adaptive Intelligence for Secure Distributed Systems

Observe. Assess. Authorize. Respond.

Website: aeglysai.com · Repository: shubh-techie/AeglysAI

The project was previously named AegisAI. See the AEGLYSAI-013B migration guide for renamed build paths, compatibility identifiers and preserved historical records.

Under development — V0.1 experimental authorization platform. A .NET 8 solution and minimal API expose GET /health and authenticated GET /identity; Models A/B/C have experimental authorization decision endpoints.

AeglysAI is intended to explore adaptive authorization, contextual risk assessment, behavioral anomaly detection, and policy-controlled response in distributed systems.

Status

• IMPLEMENTED: .NET 8 Clean Architecture solution, nullable reference types, health endpoint, JWT authentication, Models A/B/C authorization, unit tests, integration tests, architecture tests, structured audit, local Docker workflow, documentation, and offline synthetic behavioral dataset tools.
• PLANNED: Model D production integration, live context, protected-operation enforcement, durable audit, production identity-provider integration and deployment.
• EXPERIMENTAL: Models A/B/C synthetic engine-only smoke runs and ACBSD behavioral detector/recommendation evaluation; results establish no operational efficacy.

No production datasets, operational effectiveness, or publications are claimed. Synthetic smoke results validate the research framework and illustrate limitations; they support no broad performance claims.

AEGISAI-013 adds locally tested secret/disclosure gates and private-material ignore guards. Existing audit findings remain NOT CLEARED; publication is on hold. Public-safe behavioral research is now available separately; Model D authorization and confidential mechanisms remain unimplemented. See the audit and baseline assessment, security policy and local scan instructions. Hosted security CI and required-check settings remain NOT VERIFIED.

Quick Start — local Docker development

Prerequisites: Git, a POSIX shell, Docker with Compose, and a running Linux container daemon. Initial builds download images/packages. Clone this repository using its hosting URL, then run from the clone root:

git clone https://github.com/shubh-techie/AeglysAI.git AeglysAI
cd AeglysAI
./dev up                  # Build, generate temporary local credentials, start API
./dev health              # GET /health; also available at http://127.0.0.1:5080/health
./dev demo                # Exercise A/B/C and show decisions + audit correlation IDs
./dev logs                # JSON decision audit; Ctrl-C stops following
./dev test                # Full Release test suite
./dev experiment my-smoke  # New output directory: research/results/my-smoke/
./dev down

The demo uses synthetic identities and static policy/context fixtures. Local credentials expire after one hour; rerun ./dev up to rotate them. The API validates signed JWTs; Development-only trust is not a production identity provider. STEP_UP/LIMIT are recommendations, with no challenge/rate enforcement yet.

See environment specification, reproduction details, and the V0.1 readiness report for validation and limitations.

History

This repository originated as Securing-Microservices in 2022. AeglysAI development begins in 2026; no intervening activity is claimed. The old GloboTicket application is removed from the current working tree and will not be reused. Its historical commits remain recoverable at securing-microservices-legacy (b9518fa).

See project history and the development log.

Repository structure

AGENTS.md                    Agent instructions and engineering rules
docs/aegisai/
  PROJECT_HISTORY.md         Historical provenance
  DEVELOPMENT_LOG.md         Chronological AeglysAI development record
  architecture/              Architecture documentation
  adr/                       Architecture decision records
  specs/                     Specifications
  research/                  Research methodology and documentation
  threat-model/              Threat modeling
src/                         Domain, Application, Infrastructure, Api
tests/                       Domain, Application, Integration, Architecture tests
research/
  datasets/                  Dataset provenance and future data
  acbsd/                     Offline synthetic behavioral dataset and benchmark
  experiments/               Reproducible experiment definitions
  notebooks/                 Exploratory analysis
  results/                   Actual experiment outputs
benchmarks/                  Executable synthetic A–C experiment framework
deployment/
  docker/                    Local API container and development tools
  kubernetes/                Future Kubernetes manifests
papers/                      Future research manuscripts

Empty directories contain .gitkeep placeholders; their presence does not imply implemented functionality. Existing planning documents remain under docs/aegisai/.

Development

Read AGENTS.md before every task. New implementation must target .NET 8, follow Clean Architecture and SOLID, include meaningful tests, and contain no secrets. Clearly distinguish IMPLEMENTED, PLANNED, and EXPERIMENTAL work. Never fabricate research evidence or rewrite Git history.

With a .NET 8 SDK installed, run from the repository root:

dotnet restore
dotnet build
dotnet test
dotnet run --project src/AeglysAI.Api -- --urls http://localhost:5080

GET http://localhost:5080/health returns {"status":"healthy"}. This checks process liveness only. Domain and Application tests cover RBAC concepts, decision rules, and identity invariants; integration and architecture tests cover the implemented foundation.

See SPEC-002 and ADR-001.

License

No root LICENSE file is currently present; no license is asserted here.

Authentication baseline

IMPLEMENTED: standard JWT bearer authentication and a provider-neutral Application identity boundary. /health remains public; /identity requires a validated token. Provider deployments require authority and audience configuration. The explicitly opted-in local Docker environment uses temporary Development-only public-key trust. See SPEC-004 for example configuration, validation rules, tests, and remaining provider integration work.

Model A — RBAC baseline

POST /authorization/evaluate accepts {"resource":"reports","action":"read"} for the authenticated caller and returns ALLOW or DENY with a reason and policy version. Roles and permissions come from server configuration; the default policy has no grants. This experimental endpoint evaluates decisions without executing protected actions. See SPEC-005 for configuration, assumptions, algorithm, test scenarios, and limitations. Model B adds ABAC; Model C adds deterministic contextual risk.

Model B — RBAC + ABAC

POST /authorization/evaluate/model-b accepts the same resource/action request. It requires an RBAC grant and all applicable ABAC conditions to pass. Subject, resource, and environment attributes come from server configuration, never request attribute bags. Missing attributes or applicable rules deny. See SPEC-006 and ADR-003. These are experimental software baselines; production behavioral integration remains PLANNED. Offline behavioral research is available separately in ACBSD. Model C adds deterministic contextual risk.

Model C — deterministic contextual risk

POST /authorization/evaluate/model-c adds a fixed weighted score after RBAC and ABAC allow. It returns ALLOW, DENY, STEP_UP, or LIMIT with risk level and signal contributions. Context is server-owned simulation data; missing context denies. This is a deterministic heuristic, not AI or ML. STEP_UP/LIMIT are recommendations with obligations, not implemented enforcement. See SPEC-007 and ADR-004.

Authorization audit and observability

IMPLEMENTED: one structured decision event per completed Model A/B/C API evaluation, with generated correlation ID, pseudonymized identifiers, outcome/reasons, optional risk, UTC timestamp, and processing duration. .NET ActivitySource/Meter instrumentation is OpenTelemetry-compatible; no exporter or Kafka is configured. Audit failures do not change experimental decisions. See SPEC-008 for data minimization and best-effort delivery limits. Durable audit remains PLANNED.

Reproducible synthetic experiments

An executable A–C engine-only comparison runner, synthetic scenarios, and generated smoke artifacts are available. See research/README for exact Release build/test/run commands and SPEC-009 for measurement boundaries. Model D authorization remains PLANNED. The separate ACBSD research package adds EXPERIMENTAL synthetic behavioral detection-quality analysis and recommendation-only evaluation. Smoke measurements do not establish production performance or security effectiveness.

Research definition

AEGISAI-012 defines the research program, primary question and RQ1–RQ4, and unproven H1–H4. Model D remains PLANNED RESEARCH. The proposed contribution is subject to literature and prior-art review; no effectiveness, novelty or patentability is established. Consult the claims register before public claims.

Community participation

See community documentation, contribution process and code of conduct. Community claims follow the versioned evidence standard. Synthetic examples establish no real adoption or impact. The roadmap identifies separate dependent work packages.