From 07251d7714694913fd11be76229780c0c7f2e3aa Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:30:42 +0200 Subject: [PATCH 01/11] docs(public): add evidence-first global launch brief --- docs/public/AEGIS_GLOBAL_LAUNCH.md | 118 +++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 docs/public/AEGIS_GLOBAL_LAUNCH.md diff --git a/docs/public/AEGIS_GLOBAL_LAUNCH.md b/docs/public/AEGIS_GLOBAL_LAUNCH.md new file mode 100644 index 000000000..d2fb4d8a6 --- /dev/null +++ b/docs/public/AEGIS_GLOBAL_LAUNCH.md @@ -0,0 +1,118 @@ +# AEGIS Ω — Evidence-Governed Agent Execution + +AEGIS Ω is an open-source control substrate for AI systems that need to do more than generate plausible output. + +It is built around a simple operational question: + +> When an AI agent acts, can an independent reviewer determine what it was allowed to do, what state it observed, what action it took, what evidence it produced, and whether the result can be replayed? + +## The problem + +Agent systems are moving from chat into code, infrastructure, finance, enterprise workflows, security operations, and public-sector processes. Identity and access control are necessary, but they do not by themselves prove that an agent's action was justified by the task, state, authority, and evidence available at execution time. + +AEGIS focuses on that execution gap. + +## The AEGIS model + +```text +operator intent + ↓ +typed work order + ↓ +scoped capability + authority + ↓ +policy / admission gate + ↓ +execution + ↓ +immutable receipt + ↓ +outcome verification + ↓ +replay / compensation / closure +``` + +Core design rules: + +- capability does not imply authority; +- model confidence does not imply evidence; +- execution does not imply successful outcome; +- an external side effect must be attributable to an admitted action; +- deterministic receipts and replay are part of the runtime contract, not an afterthought. + +## What can be inspected today + +The repository contains runnable reference implementations for replay-verifiable governance envelopes, cross-runtime canonicalization, tamper-evident lineage, deterministic admission primitives, and multi-language verification. + +The fastest public proof path is already in the repository: + +```bash +python3 genomics/test_replay_proof.py +python3 verifiable/test_generality.py +bash verifiable/cross_language/verify.sh +python3 verifiable/certify_all.py --twice +``` + +These examples intentionally make a bounded claim: they demonstrate the governance and verification envelope, not universal domain intelligence. + +## Research frontier + +Active research extends the same architecture toward: + +- evidence-bounded operator models; +- task-scoped agent authority; +- leases and fencing for consequential actions; +- runtime capability admission; +- independently verifiable execution receipts; +- outcome-aware replay and compensation; +- multi-agent systems where consensus cannot assign itself truth. + +Research candidates are explicitly separated from production claims. + +## Who AEGIS is for + +AEGIS is relevant to teams building or evaluating: + +- AI agent security; +- non-human identity governance; +- autonomous workflow infrastructure; +- AI assurance and auditability; +- regulated or high-consequence agent systems; +- public-sector automation; +- multi-agent orchestration; +- developer platforms that need deterministic execution evidence around probabilistic models. + +## Collaboration + +We are looking for four kinds of external counterparties: + +1. **Independent evaluators** — reproduce the reference proofs and try to break the invariants. +2. **Design partners** — bring one consequential agent workflow and test AEGIS as the execution-governance layer around it. +3. **Research collaborators** — study agent metacognition, operator-model calibration, runtime authority, and evidence-governed multi-agent systems. +4. **Funding / institutional partners** — support reproducible work on trustworthy agent execution and AI assurance. + +## A concrete evaluation proposal + +Give AEGIS one agent workflow with a meaningful side effect. We will define: + +- task identity; +- actor identity; +- delegated authority; +- capability scope; +- state preconditions; +- admission policy; +- execution receipt; +- outcome verifier; +- replay / compensation path. + +Then we deliberately test stale state, excessive privilege, ambiguous instructions, late receipts, and unverified outcomes. + +The useful result is not a convincing demo. It is a workflow an external reviewer can falsify. + +## Contact + +Repository: `Aegis-Omega/AEGIS-OMEGA` + +Project: **AEGIS Ω — Evidence-Governed Collective Intelligence Infrastructure** + +Operator: **Tarik Skalić · Bihać, Bosnia and Herzegovina** From cf9f4fd88094bbf2c94c9b45dc6324caf407ddb5 Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:31:07 +0200 Subject: [PATCH 02/11] docs(public): add partner evaluation brief --- docs/public/AEGIS_PARTNER_BRIEF.md | 108 +++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 docs/public/AEGIS_PARTNER_BRIEF.md diff --git a/docs/public/AEGIS_PARTNER_BRIEF.md b/docs/public/AEGIS_PARTNER_BRIEF.md new file mode 100644 index 000000000..9d136f8bc --- /dev/null +++ b/docs/public/AEGIS_PARTNER_BRIEF.md @@ -0,0 +1,108 @@ +# AEGIS Ω — Partner Evaluation Brief + +## One-line proposition + +AEGIS Ω adds an evidence and authority layer around autonomous agents so that consequential actions can be admitted, attributed, verified, replayed, or rejected under explicit policy. + +## Why now + +The agent-security market is converging on identity, least privilege, lifecycle governance, runtime controls, and observability. AEGIS is designed to complement those layers with task-level execution evidence: + +```text +identity + authorization + ↓ +current task / state / policy + ↓ +execution admission + ↓ +receipt + ↓ +outcome verification +``` + +The distinction matters because a valid identity can still attempt the wrong action, at the wrong time, against stale state, with excessive scope. + +## Evaluation wedge + +For a first partner evaluation, do not replace the partner's identity, model, orchestration, or cloud stack. + +Wrap one existing agent action with an AEGIS execution contract. + +Example: + +```text +Agent proposes a database / infrastructure / workflow mutation +→ AEGIS checks actor + task + capability + authority + state precondition +→ action is admitted or denied +→ execution emits a deterministic receipt +→ independent verifier checks observed outcome +→ replay reconstructs the decision +``` + +## What AEGIS can demonstrate without a production integration + +- deterministic, tamper-evident execution lineage; +- cross-language canonicalization and replay; +- fail-closed admission behavior; +- explicit separation between model confidence, evidence, and authority; +- denial cases for stale or inadmissible actions; +- bounded research implementations for operator-model calibration and agent-governance semantics. + +## High-fit partner classes + +### Identity / NHI platforms + +Fit: identity systems answer **who** the agent is and what credentials it holds. AEGIS can evaluate **whether this action is admissible now** and bind the result to execution evidence. + +Evaluation target: identity → delegated scope → time/state-bound action → receipt. + +### Agent-security platforms + +Fit: add deterministic execution evidence and replay to runtime guardrails. + +Evaluation target: tool invocation or MCP/A2A action → policy decision → outcome certificate. + +### Cloud / model platforms + +Fit: make heterogeneous model and tool calls auditable under one evidence contract. + +Evaluation target: model-selected action → external capability → provider receipt → independent outcome verification. + +### Regulated / public-sector automation + +Fit: traceability, human authority, state preconditions, evidence retention, replay, and explicit `NOT_ESTABLISHED` outcomes. + +Evaluation target: one bounded workflow, not a claim of universal legal compliance. + +## Partner ask + +The smallest useful ask is: + +> Give us one real agent workflow whose side effect matters. Let us wrap it with an evidence-bound execution contract and let your team try to break the guarantees. + +Expected evaluation artifacts: + +- threat model; +- typed action contract; +- authorization/admission policy; +- positive and negative test vectors; +- deterministic execution receipt; +- independent verifier output; +- replay instructions; +- explicit `not_proved[]` section. + +## What we do not claim + +AEGIS does not claim that identity, event sourcing, two-phase commit, BFT, capability security, or replay were invented here. The research question is whether these primitives can be combined into a coherent execution-governance substrate for probabilistic agent systems. + +We do not treat specifications as deployments or internal test results as independent third-party validation. + +## Desired relationships + +- technical evaluation; +- integration study; +- design partnership; +- funded research collaboration; +- security evaluation; +- reproducibility review; +- bounded enterprise or public-sector pilot. From 0b01c9475581c464da7532771fd847fbeb9490e1 Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:31:29 +0200 Subject: [PATCH 03/11] docs(public): add ChatGPT plugin distribution concept --- docs/public/AEGIS_CHATGPT_PLUGIN_SPEC.md | 145 +++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 docs/public/AEGIS_CHATGPT_PLUGIN_SPEC.md diff --git a/docs/public/AEGIS_CHATGPT_PLUGIN_SPEC.md b/docs/public/AEGIS_CHATGPT_PLUGIN_SPEC.md new file mode 100644 index 000000000..d31594892 --- /dev/null +++ b/docs/public/AEGIS_CHATGPT_PLUGIN_SPEC.md @@ -0,0 +1,145 @@ +# AEGIS Ω — ChatGPT Plugin / Apps SDK Distribution Concept + +## Product thesis + +Use ChatGPT as a distribution surface for AEGIS verification rather than as another generic chatbot. + +Working product name: + +**AEGIS Evidence Governor** + +The first public version should be deliberately narrow and safe: a read/verify experience that turns a proposed agent action or supplied execution artifact into a structured evidence and authority assessment. + +## User jobs + +A user should be able to ask: + +- "Can this agent action be admitted under this policy?" +- "Verify this execution receipt." +- "Compare this observed outcome to the declared action." +- "Show me what is proved versus not proved." +- "Replay this deterministic evidence chain." +- "Explain why this action was denied." + +## V1 tool surface + +### `verify_receipt` + +Input: +- receipt or receipt reference; +- expected schema/version; +- optional expected task/actor/resource identifiers. + +Output: +- structural validity; +- integrity result; +- replay result where supported; +- contradictions; +- `not_proved[]`. + +### `evaluate_admission` + +Input: +- typed action proposal; +- capability scope; +- authority evidence; +- current state/precondition evidence; +- policy contract. + +Output: +- `ADMIT | DENY | REVIEW | BLOCKED`; +- exact gates used; +- evidence references; +- no side effect in V1. + +### `explain_evidence` + +Input: +- one AEGIS certificate, ledger entry, or test artifact. + +Output: +- what it establishes; +- what it does not establish; +- reproduction instructions where available. + +### `run_public_demo` + +Runs a bounded, deterministic demonstration included in the public repository and returns the resulting certificate. + +## Safety posture + +V1 should expose **no consequential external write tool**. + +This has three advantages: + +1. the app can demonstrate the AEGIS thesis without asking users to trust AEGIS with production authority; +2. review and threat modelling are substantially simpler; +3. the public artifact becomes a funnel into deeper enterprise evaluations. + +A later enterprise version may expose mediated write actions only after task-level authority, resource scope, state preconditions, confirmation rules, and outcome verification are defined. + +## Chat-native experience + +The UI should make evidence status immediately visible: + +```text +ACTION proposed database migration +ACTOR agent://finance-ops/07 +CAPABILITY db.schema.migrate +AUTHORITY VALID / scoped +STATE PRECONDITION STALE +VERDICT DENY +WHY target schema changed after authorization +PROVED identity, policy, observed state +NOT PROVED business outcome +``` + +The product should avoid anthropomorphic "agent thinks" language. It should present claims, evidence, authority, observations, and outcomes as separate fields. + +## Directory positioning + +Category fit: +- Developer Tools +- Security +- Productivity / Enterprise workflows + +Short description: + +> Verify what an AI agent was allowed to do, what evidence it used, and whether the execution can be replayed. + +Long description: + +> AEGIS Evidence Governor is an evidence-first control and verification layer for agentic workflows. It checks action proposals and execution receipts against explicit capability, authority, state, and policy constraints, then returns a reproducible verdict with clear `proved` and `not_proved` boundaries. + +## Conversion path + +```text +ChatGPT user +→ public verifier/demo +→ reproducible evidence result +→ GitHub repository +→ integration/evaluation request +→ design partner / research collaboration / paid pilot +``` + +## Submission readiness gates + +Before public submission: + +- stable remote MCP endpoint; +- deterministic public demo; +- privacy policy; +- support contact; +- accurate tool annotations; +- threat model; +- abuse cases; +- app-directory metadata; +- test instructions; +- no unsupported production/security claims; +- public documentation for data retention and logging. + +## Build principle + +Do not build an "AEGIS assistant" that merely talks about AEGIS. + +Build an **AEGIS verifier that does something independently checkable**. From 06a13c0408e6154ad7ddf51e1654c8cfe1b16cdf Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:32:32 +0200 Subject: [PATCH 04/11] docs(strategy): add global expansion wave 1 --- .../strategy/AEGIS_GLOBAL_EXPANSION_WAVE_1.md | 275 ++++++++++++++++++ 1 file changed, 275 insertions(+) create mode 100644 docs/strategy/AEGIS_GLOBAL_EXPANSION_WAVE_1.md diff --git a/docs/strategy/AEGIS_GLOBAL_EXPANSION_WAVE_1.md b/docs/strategy/AEGIS_GLOBAL_EXPANSION_WAVE_1.md new file mode 100644 index 000000000..436691ad4 --- /dev/null +++ b/docs/strategy/AEGIS_GLOBAL_EXPANSION_WAVE_1.md @@ -0,0 +1,275 @@ +# AEGIS Ω — Global Expansion Wave 1 + +Date context: 2026-08 + +Purpose: convert existing AEGIS technical capital into external evaluation, distribution, funding, partnerships, and revenue. + +This is a conversion plan, not a provenance project. + +## 1. Immediate funding / resource targets + +### Digital Europe — DIGITAL-2026-AI-DATA-10-COMPLIANCE + +Status: OPEN +Deadline: 2026-10-01 17:00 CEST +Primary source: https://digital-strategy.ec.europa.eu/en/events/info-session-call-proposals-digital-solutions-regulatory-compliance-through-data + +Fit: +- digital compliance infrastructure; +- machine-readable evidence; +- traceable reporting; +- accountable automation; +- public/private sector applicability. + +AEGIS pitch: + +> Evidence-governed automation for compliance workflows: every consequential action is bound to actor, authority, state, evidence, receipt, and outcome verification. + +Critical next step: identify consortium partners and decide whether AEGIS participates as technical partner or coordinator. + +### EIC Accelerator 2026 + +Status: OPEN +Remaining full-proposal batching dates: 2026-09-02 and 2026-11-04 +Primary source: https://eic.ec.europa.eu/eic-funding-opportunities_en + +Fit: +- deep-tech commercialization; +- developer/security infrastructure; +- enterprise agent governance. + +Critical next step: qualify entity/SME eligibility, TRL, IP/commercial structure, and whether a short proposal must precede the desired full-proposal batch. + +### Long-Term Future Fund + +Status: ALWAYS OPEN +Typical EA Funds application range shown by current application surface: USD 1,000–500,000 +Primary source: https://funds.effectivealtruism.org/apply-for-funding + +Fit: +- technical AI safety; +- AI security; +- demonstration projects; +- infrastructure supporting safe advanced AI. + +Candidate proposal: + +**Evidence-Bound Runtime Authority for Autonomous Agent Systems** + +Deliverables: +- open-source runtime reference implementation; +- adversarial benchmark; +- reproducibility package; +- independent external evaluation target. + +### OpenAI Researcher Access Program + +Status: OPEN on current grants surface +Resource: up to USD 1,000 in API credits +Review cadence: quarterly +Primary source: https://grants.openai.com/prog/openai_researcher_access_program/ + +Fit: +- metacognitive calibration; +- agentic oversight; +- adversarial reliability; +- safety properties under adversarial input. + +Candidate proposal: + +**Operator-Model Hallucination and Evidence-Bounded Agent Routing** + +### OpenAI Cybersecurity Grant Program / Trusted Access for Cyber + +Status: current application surface available +OpenAI announced USD 10M in API credits for teams through the Cybersecurity Grant Program. +Primary sources: +- https://openai.com/index/trusted-access-for-cyber/ +- https://openai.com/form/cybersecurity-grant-program/ + +Fit: +- defensive agent security; +- open-source security infrastructure; +- vulnerability prevention through task-scoped runtime authority; +- agent privilege / tool-use containment. + +Candidate proposal: + +**Capability-Bound Agent Execution: Preventing Tool Misuse and Privilege Drift in Autonomous Security Workflows** + +## 2. Distribution target — ChatGPT Plugin Directory + +OpenAI accepts app submissions for review and publication. The Plugin directory is now the primary discovery surface for workflow capabilities across ChatGPT and Codex. + +AEGIS product candidate: + +**AEGIS Evidence Governor** + +V1 must be read/verify only: +- verify receipt; +- evaluate admission without executing a side effect; +- explain proved / not_proved boundaries; +- run deterministic public demo. + +Conversion funnel: + +```text +ChatGPT discovery +→ verifier/demo +→ reproducible result +→ GitHub +→ partner evaluation request +→ paid pilot / research collaboration +``` + +See `docs/public/AEGIS_CHATGPT_PLUGIN_SPEC.md`. + +## 3. Strategic enterprise partner targets + +These are not generic logo targets. Each currently works on the same emerging problem from a different control layer. + +### Microsoft — Entra Agent ID / Agent Governance Toolkit + +Observed market problem: +- dedicated agent identities; +- authorization and governance; +- runtime agent security; +- agent lifecycle and accountability. + +AEGIS complement: + +**identity says who the agent is; AEGIS binds whether a particular consequential action is admissible under current task/state/evidence and produces a replayable receipt.** + +Smallest credible ask: + +> Evaluate one Entra-identified agent action through an AEGIS execution-admission and receipt layer. + +### CyberArk — Secure AI Agents + +Observed market problem: +- agent identities; +- privilege controls; +- MCP access; +- just-in-time privilege and runtime monitoring. + +AEGIS complement: +- purpose/task binding; +- state-bound admission; +- deterministic execution receipts; +- post-action outcome verification. + +Smallest credible ask: + +> Combine privileged identity controls with an evidence-bound action receipt for one MCP workflow. + +### Okta — AI Agent Governance + +Observed market problem: +- lifecycle governance; +- regulated environments; +- authorization/accountability for autonomous identities. + +AEGIS complement: +- execution-level evidence beyond identity lifecycle; +- explicit `OUTCOME_UNKNOWN` handling; +- replay and compensation semantics. + +Smallest credible ask: + +> Joint technical evaluation of identity governance + task-level execution governance in a regulated workflow. + +### Palo Alto Networks — Agentic Identity Security / MCP access controls + +Observed market problem: +- AI agents as privileged identities; +- MCP data access; +- least-privilege brokerage; +- visibility and runtime governance. + +AEGIS complement: +- deterministic proof of the admission decision; +- state/freshness constraints; +- independent outcome verification. + +Smallest credible ask: + +> Red-team an AEGIS-wrapped MCP action where identity is valid but task authority or state is stale. + +## 4. Commercial wedge + +Do not sell "AGI OS" first. + +Sell one measurable control surface: + +**Evidence-bound consequential agent execution.** + +Buyer problem: + +> "Our agent has valid credentials and can call the tool. How do we prove this specific action was authorized, appropriate to current state, and actually produced the declared outcome?" + +Initial paid offer: + +### AEGIS Agent Action Assurance — Evaluation Sprint + +Scope: +- one agent workflow; +- one consequential external action; +- threat model; +- typed execution contract; +- positive + adversarial test cases; +- deterministic receipt; +- outcome verifier; +- replay package; +- integration recommendations. + +Commercial objective: +- paid technical evaluation first; +- platform integration second. + +Do not wait for a universal production runtime before selling a bounded evaluation. + +## 5. Fame / reputation loop + +One technical result should generate multiple surfaces: + +```text +reproducible demo +→ GitHub proof +→ technical write-up +→ short visual explanation +→ researcher outreach +→ security-community outreach +→ grant application evidence +→ partner evaluation artifact +``` + +Public content rule: + +**show a failure that AEGIS blocks.** + +Better than "AEGIS is revolutionary": + +> This agent had valid credentials. The action was still denied because its authority was stale. Here is the receipt and replay. + +## 6. Wave-1 execution order + +1. Ship public launch brief and partner brief as reviewable GitHub PR. +2. Turn existing replay proof into a 60–90 second deterministic demo. +3. Build `AEGIS Evidence Governor` minimal ChatGPT Plugin / Apps SDK surface. +4. Prepare LTFF and OpenAI Cybersecurity Grant proposals from the same technical wedge. +5. Prepare Digital Europe partner one-pager and consortium outreach package. +6. Prepare four enterprise evaluation pitches: Microsoft, CyberArk, Okta, Palo Alto Networks. +7. Do not send or publish until each outward-facing artifact has a final operator review. + +## Success metric + +Not number of documents. + +```text +external technical reviews ++ qualified partner conversations ++ submitted funding applications ++ plugin users ++ paid evaluations ++ independently reproduced proofs +``` From 1452da0024a2c61f6d5ed342da6cbfad012013e3 Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:34:21 +0200 Subject: [PATCH 05/11] docs(outreach): prepare unprompted 2026 CFP draft --- docs/outreach/UNPROMPTED_2026_CFP_DRAFT.md | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 docs/outreach/UNPROMPTED_2026_CFP_DRAFT.md diff --git a/docs/outreach/UNPROMPTED_2026_CFP_DRAFT.md b/docs/outreach/UNPROMPTED_2026_CFP_DRAFT.md new file mode 100644 index 000000000..9266fd30c --- /dev/null +++ b/docs/outreach/UNPROMPTED_2026_CFP_DRAFT.md @@ -0,0 +1,91 @@ +# [un]prompted II 2026 — CFP Draft + +Target track: **Build** (secondary: Govern) +Conference: San Francisco, October 27–29, 2026 +CFP deadline: September 8, 2026 + +## Title + +**Determinism Lives Outside the Model: Replay-Verifiable Governance for AI Agent Actions** + +## Abstract — <=200 words + +Modern AI agents can authenticate correctly, call legitimate tools, and still perform an inadmissible action because the task, authority, state, or evidence changed after the agent was authorized. Prompt guardrails do not solve that problem, and model confidence cannot be treated as an authorization primitive. + +This talk presents AEGIS Ω, an open-source experimental runtime that places a deterministic governance envelope around probabilistic agent behavior. The envelope separates capability from authority, canonicalizes evidence, hash-chains execution lineage, and supports replay from genesis so divergence becomes a detectable failure instead of an unverifiable story. + +The talk is built around runnable artifacts rather than architecture slides. We will reproduce the same governed result across Python, Node.js, and Rust; deliberately tamper with stored evidence; and show the verifier identify the broken stage. We then extend the pattern to consequential agent actions: task-scoped authority, state preconditions, admission decisions, receipts, and explicit `OUTCOME_UNKNOWN` semantics. + +The result is not a claim that models become deterministic. It is a narrower security property: stochastic models can operate inside a system whose authority decisions and evidence trail are independently inspectable and replayable. + +## Detailed outline + +1. **Why valid credentials are not enough — 4 min** + - agent identity vs capability vs authority; + - stale state and confused-deputy failure; + - why model confidence cannot authorize side effects. + +2. **The deterministic governance envelope — 5 min** + - canonical evidence; + - append-only lineage; + - execution receipts; + - replay invariants. + +3. **Live proof: three runtimes, one fingerprint — 6 min** + - Python / Node.js / Rust canonicalization; + - tamper one artifact; + - verifier detects divergence. + +4. **From replay to runtime authority — 5 min** + - task-scoped action contract; + - leases / fencing / state freshness; + - `ADMIT`, `DENY`, `REVIEW`, `BLOCKED`; + - `OUTCOME_UNKNOWN != SUCCESS`. + +5. **What failed and what remains unproved — 5 min** + - GPU nondeterminism boundary; + - verifier scaling; + - draft operator-model work; + - why specifications and passing local tests are not production proof. + +## Evidence supporting the talk + +Public repository: `Aegis-Omega/AEGIS-OMEGA` + +Runnable examples currently exposed in the repository: + +```bash +python3 genomics/test_replay_proof.py +python3 verifiable/test_generality.py +bash verifiable/cross_language/verify.sh +python3 verifiable/certify_all.py --twice +``` + +Repository documentation explicitly limits the claim to the governance envelope rather than domain accuracy. + +Additional evidence to attach before CFP submission: + +- exact-head CI receipt for the demo branch; +- screen recording of the tamper/replay failure; +- one concise architecture diagram; +- link to the public launch/evaluation brief; +- negative-control result for stale or excessive authority. + +## Speaker bio — <=100 words + +Tarik Skalić is an independent systems builder from Bihać, Bosnia and Herzegovina, working on AEGIS Ω: an open-source research and engineering project for evidence-governed AI agent execution. His work focuses on deterministic control around probabilistic models, replay-verifiable evidence, task-scoped authority, agent metacognition, and multi-agent governance. AEGIS grew from earlier experiments in persistent simulation, metacognitive evaluation, and autonomous system control into a public repository spanning Rust, TypeScript, Python, cross-language verification, and adversarial governance tests. + +## Submission positioning + +Do not pitch AEGIS as a product presentation. + +Lead with the security property and the failure: + +> The agent had valid identity and capability. The action was still invalid. Here is how the runtime proved it. + +## Final submission blockers + +- run/record the exact public demo on current head; +- choose one authority-denial negative control that is already runnable or can be completed without speculative claims; +- verify every benchmark/test count included in slides; +- remove any reference to unverified municipal/production deployment. From 5497a9785969f7ab4caae7342960e7e80fa7eaa8 Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:34:42 +0200 Subject: [PATCH 06/11] docs(outreach): prepare OpenAI developer showcase submission draft --- .../OPENAI_SHOWCASE_SUBMISSION_DRAFT.md | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 docs/outreach/OPENAI_SHOWCASE_SUBMISSION_DRAFT.md diff --git a/docs/outreach/OPENAI_SHOWCASE_SUBMISSION_DRAFT.md b/docs/outreach/OPENAI_SHOWCASE_SUBMISSION_DRAFT.md new file mode 100644 index 000000000..39880665d --- /dev/null +++ b/docs/outreach/OPENAI_SHOWCASE_SUBMISSION_DRAFT.md @@ -0,0 +1,70 @@ +# OpenAI Developer Showcase — AEGIS Ω Submission Draft + +## Project name + +**AEGIS Evidence Governor** + +## One-line description + +A replay-verifiable governance layer that shows what an AI agent was allowed to do, what evidence it used, and whether the resulting execution can be independently checked. + +## Short description + +AEGIS Evidence Governor demonstrates a security pattern for agentic systems: keep probabilistic reasoning separate from deterministic authority and evidence. A user supplies or runs a bounded agent workflow; AEGIS returns a structured admission result, tamper-evident receipt, `proved` / `not_proved` boundary, and replay path. + +The demo intentionally avoids the claim that a model itself becomes deterministic. Instead, it shows how stochastic model output can operate inside a deterministic governance envelope. + +## Why it is useful + +As agents gain access to APIs, data, code, and infrastructure, valid credentials do not prove that a specific action was appropriate to the current task or state. AEGIS adds an execution-level verification layer around those actions. + +## Demo flow + +1. User proposes an action. +2. AEGIS evaluates capability, authority, policy, and state evidence. +3. The action is admitted or denied. +4. The execution emits a canonical receipt. +5. The verifier replays the evidence chain. +6. A deliberate tamper changes the fingerprint and identifies the broken stage. + +## Public artifact + +Repository: `Aegis-Omega/AEGIS-OMEGA` + +Current reproducible proof commands: + +```bash +python3 genomics/test_replay_proof.py +python3 verifiable/test_generality.py +bash verifiable/cross_language/verify.sh +python3 verifiable/certify_all.py --twice +``` + +## Proposed ChatGPT-native version + +A read/verify-only Apps SDK / MCP experience with tools: + +- `verify_receipt` +- `evaluate_admission` +- `explain_evidence` +- `run_public_demo` + +No consequential external writes in V1. + +## Submission assets to produce + +- 60–90 second demo video; +- one animated or interactive receipt visualization; +- public hosted MCP endpoint; +- public privacy policy and support page; +- screenshot of `ADMIT` and `DENY` cases; +- exact reproduction instructions; +- public GitHub link. + +## Project story + +AEGIS Ω began as an attempt to make AI systems fail loudly instead of silently: distinguish a model's claim from observed state, separate capability from authority, and preserve enough evidence that an independent verifier can reconstruct what happened. The current public demo compresses that thesis into a small, falsifiable artifact. + +## Review-safe scope statement + +The submission demonstrates replay-verifiable governance primitives and bounded agent-action verification. It does not claim universal AI safety, AGI, legal certification, or production deployment across external organizations. From fb8b502a13177cbbf38959a32b7eed23a23f99ea Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:37:24 +0200 Subject: [PATCH 07/11] funding: prepare LTFF application draft --- docs/funding/LTFF_APPLICATION_DRAFT.md | 211 +++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 docs/funding/LTFF_APPLICATION_DRAFT.md diff --git a/docs/funding/LTFF_APPLICATION_DRAFT.md b/docs/funding/LTFF_APPLICATION_DRAFT.md new file mode 100644 index 000000000..eb0fef198 --- /dev/null +++ b/docs/funding/LTFF_APPLICATION_DRAFT.md @@ -0,0 +1,211 @@ +# Long-Term Future Fund — AEGIS Ω Application Draft + +Status: submission-ready draft, NOT SUBMITTED +Target fund: Long-Term Future Fund (EA Funds) +Current public application surface: always open; general EA Funds range USD 1,000–500,000. +Primary source: https://funds.effectivealtruism.org/apply-for-funding + +## Project title + +**Evidence-Bound Runtime Authority for Autonomous AI Agents** + +## Funding request + +**USD 120,000 / 12 months** + +This request is intentionally below the program-wide maximum. The goal is to fund one narrow, independently testable safety program rather than the entire AEGIS Ω roadmap. + +## One-sentence summary + +Build and independently evaluate an open-source runtime layer that prevents autonomous AI agents from converting model confidence, credentials, or tool availability into consequential authority without task-, state-, policy-, and evidence-bound admission. + +## Problem + +As AI agents gain the ability to modify code, infrastructure, databases, workflows, and external services, traditional identity and access controls are necessary but incomplete. A valid identity may possess a valid credential and still attempt an action that is no longer authorized, is based on stale state, exceeds task scope, or produces an outcome that cannot be verified. + +Most agent-safety approaches concentrate on model behavior, prompt-level policy, or monitoring. This project studies a complementary system property: **can consequential authority be mechanically bounded outside the model and independently reconstructed after execution?** + +The central safety invariant is: + +```text +model capability != authority +model confidence != evidence +execution != verified outcome +``` + +## Proposed work + +We will develop a bounded open-source reference implementation and adversarial benchmark around five transitions: + +1. **Typed action proposal** — actor, task, resource, capability, intended side effect. +2. **Authority admission** — delegated scope, lease/fence, policy, state freshness. +3. **Consequential execution** — no external side effect without an admitted action. +4. **Execution receipt** — deterministic, tamper-evident evidence binding proposal to observed execution. +5. **Outcome verification** — explicit separation of `SUCCESS`, `FAILURE`, and `OUTCOME_UNKNOWN`, with replay or compensation where feasible. + +## Research questions + +1. Can task-level authority prevent failures that identity/IAM alone cannot distinguish? +2. Which agent actions can be deterministically replayed or independently verified despite stochastic model reasoning? +3. How should stale state, late receipts, ambiguous operator intent, and partial provider failures affect authority? +4. How often do latent model/user-state inferences improperly influence routing or policy, and can evidence thresholds reduce that failure mode? +5. What minimum evidence is sufficient for an external reviewer to reproduce an agent-action verdict without trusting the originating model? + +## Existing technical base + +AEGIS Ω is already a public open-source repository with runnable reference proofs for: + +- deterministic canonicalization and SHA-256 lineage; +- replay-verifiable governance envelopes; +- tamper detection; +- cross-language verification across Python, Node.js, and Rust; +- fail-closed admission and governance primitives; +- large existing TypeScript/Rust/Python test surfaces. + +Public reproduction commands currently include: + +```bash +python3 genomics/test_replay_proof.py +python3 verifiable/test_generality.py +bash verifiable/cross_language/verify.sh +python3 verifiable/certify_all.py --twice +``` + +The proposal does **not** rely on claims of AGI, consciousness, universal hallucination elimination, or production deployment. + +## Deliverables + +### D1 — Consequential Action Contract + +A stable open schema for: +- actor identity; +- task identity; +- capability; +- delegated authority; +- resource scope; +- state preconditions; +- lease/fence; +- execution intent; +- expected outcome; +- evidence references. + +### D2 — Runtime Admission Layer + +Reference implementation supporting: + +`ADMIT | DENY | REVIEW | BLOCKED` + +with fail-closed handling for unresolved consequential ambiguity. + +### D3 — Adversarial Benchmark + +At least 100 reproducible negative-control scenarios covering: +- valid identity / invalid task authority; +- stale lease or fence; +- stale target state; +- privilege expansion; +- prompt/tool injection; +- provider timeout; +- late receipt; +- duplicate action/retry; +- outcome unknown; +- unsupported latent user/operator-state inference. + +### D4 — Receipt + Replay Package + +Cross-language deterministic verification and public reproduction harness. + +### D5 — Independent Evaluation + +Recruit at least two external technical reviewers or organizations to run the benchmark independently and publish or return reproducibility results. + +### D6 — Research Write-up + +Open technical paper covering architecture, threat model, empirical results, failure cases, limitations, and falsification criteria. + +## Milestones + +### Months 1–2 +- freeze action/receipt schemas; +- isolate canonical reference implementation; +- threat model and baseline negative controls. + +### Months 3–5 +- implement state/authority admission and adversarial harness; +- cross-runtime replay; +- automated receipts. + +### Months 6–8 +- benchmark agent/tool/provider failure modes; +- measure false-admit / false-deny behavior; +- operator-model calibration experiments. + +### Months 9–10 +- independent reproduction wave; +- red-team fixes; +- deterministic release package. + +### Months 11–12 +- final paper; +- public benchmark; +- deployment guidance and limitations. + +## Success metrics + +Primary metrics: + +- False Unauthorized Admission Rate; +- Unverifiable Action Execution Rate; +- replay success rate; +- stale-state rejection rate; +- receipt completeness; +- independent reproduction rate; +- time-to-reconstruct an incident; +- policy-elevation errors caused by unsupported latent inference. + +A negative result is useful. If the architecture cannot provide reliable evidence-bound authority under realistic provider behavior, the benchmark should expose that clearly. + +## Budget — USD 120,000 + +- Operator/research engineering: $60,000 +- External reviewers / independent reproduction / contracted security review: $20,000 +- Compute, API and cloud experimentation: $15,000 +- Test infrastructure and hardware/edge targets: $10,000 +- Research dissemination, conference/travel and reproducibility support: $7,500 +- Legal/accounting/administrative and contingency: $7,500 + +Exact budget can be resized after funder feedback. + +## Why this may matter for advanced-AI risk + +As agents become more capable, preventing every model-level error may be unrealistic. A complementary safety strategy is to ensure that **error does not automatically become authority**. + +The project therefore focuses on the boundary between cognition and consequential action. Even if an agent reasons incorrectly, the system should be able to deny an inadmissible action, preserve evidence of the attempted transition, and avoid silently classifying an unknown outcome as success. + +## Public-benefit plan + +Core schemas, benchmark cases, verifier, reference runtime, and research outputs will be released openly. The goal is to make the work reusable by other AI-safety researchers, open-source agent frameworks, and organizations evaluating agent controls. + +## Key risks and limitations + +- deterministic evidence does not make stochastic cognition deterministic; +- a receipt can prove what the instrumented system observed, not unknowable external facts; +- provider black boxes limit end-to-end verification; +- safety benefits depend on external actions actually being routed through the control boundary; +- benchmarks may underrepresent future high-autonomy workflows; +- this project does not claim a complete alignment solution. + +## Operator + +Tarik Skalić +Bihać, Bosnia and Herzegovina +AEGIS Ω / Aegis-Omega + +## Submission checklist + +- [ ] confirm requested amount and personal/entity recipient structure; +- [ ] add concise prior-work links; +- [ ] select 3 strongest runnable proof links; +- [ ] add 12-month personal runway/budget assumptions if form requests them; +- [ ] operator review; +- [ ] submit through LTFF application surface. From f883f8254f12a9ac936e8da77ea5522a8764590a Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:37:59 +0200 Subject: [PATCH 08/11] funding: prepare OpenAI cybersecurity grant draft --- .../OPENAI_CYBERSECURITY_GRANT_DRAFT.md | 186 ++++++++++++++++++ 1 file changed, 186 insertions(+) create mode 100644 docs/funding/OPENAI_CYBERSECURITY_GRANT_DRAFT.md diff --git a/docs/funding/OPENAI_CYBERSECURITY_GRANT_DRAFT.md b/docs/funding/OPENAI_CYBERSECURITY_GRANT_DRAFT.md new file mode 100644 index 000000000..a70d403de --- /dev/null +++ b/docs/funding/OPENAI_CYBERSECURITY_GRANT_DRAFT.md @@ -0,0 +1,186 @@ +# OpenAI Cybersecurity Grant Program — AEGIS Ω Draft + +Status: READY FOR OPERATOR REVIEW — NOT SUBMITTED +Program: OpenAI Cybersecurity Grant Program / Trusted Access for Cyber ecosystem +Primary sources: +- https://openai.com/index/openai-cybersecurity-grant-program/ +- https://openai.com/index/trusted-access-for-cyber/ + +## Project title + +**Capability-Bound Agent Execution: Preventing Tool Misuse and Privilege Drift in Autonomous Security Workflows** + +## Requested support + +**$50,000 equivalent support**, preferably a mix of API credits and other available program support. + +The amount is intentionally aligned to a bounded defensive open-source project and can be resized to the current program mechanism. + +## Project summary + +Security agents increasingly operate with repository, cloud, CI/CD, scanner, ticketing, and remediation tools. Existing identity controls can establish who an agent is and what credential it possesses, but a valid identity does not prove that a particular action is authorized for the current task, target, state, or point in time. + +AEGIS Ω will build an open-source defensive control layer that binds security-agent actions to task-scoped capabilities, delegated authority, resource/state preconditions, and deterministic execution receipts. The project will demonstrate that an agent can have valid credentials yet still be denied when the requested action is stale, excessive, ambiguous, or unsupported by admissible evidence. + +The system is intended for authorized defensive workflows only. + +## Defensive use cases + +The initial benchmark will cover: + +1. secure code review and finding validation; +2. patch proposal and patch verification; +3. security backlog triage; +4. threat-model generation and evidence updates; +5. controlled CI security checks; +6. defensive MCP/tool invocation; +7. remediation-plan execution in isolated test environments. + +No project milestone requires exploitation or unauthorized testing of third-party systems. + +## Core security hypothesis + +```text +VALID_IDENTITY != VALID_AUTHORITY +VALID_AUTHORITY != VALID_ACTION_NOW +VALID_ACTION != VERIFIED_OUTCOME +``` + +The project tests whether a deterministic external governance layer can reduce security-agent privilege drift and confused-deputy behavior without depending on a model to reliably self-police its own authority. + +## Technical design + +A proposed security-agent action enters an admission contract containing: + +- actor/workload identity; +- task identity; +- target resource; +- requested capability; +- delegated authority; +- lease/fence and freshness information; +- observed target state; +- policy/evidence references; +- expected side effect and outcome. + +AEGIS evaluates the contract and returns one of: + +`ADMIT | DENY | REVIEW | BLOCKED` + +An admitted execution emits a canonical, tamper-evident receipt. The verifier separately evaluates the observed outcome and preserves `OUTCOME_UNKNOWN` when a provider or environment cannot establish success or failure. + +## Adversarial scenarios + +The benchmark will include defensive failure cases such as: + +- valid repository token, wrong repository/task scope; +- valid cloud identity, expired delegated lease; +- target changed after approval; +- tool request expands beyond approved remediation; +- malicious instructions embedded in issue/code/tool output; +- retry causes duplicate side effect; +- security scanner returns ambiguous or stale evidence; +- provider timeout after a possibly committed action; +- an agent claims a patch was applied but outcome verification disagrees; +- one agent's assertion is incorrectly treated as independent verification by another. + +## Existing AEGIS base + +The public AEGIS Ω repository already contains reference implementations and tests for replay-verifiable, tamper-evident evidence handling and deterministic governance envelopes, including cross-language verification. + +Public proof commands include: + +```bash +python3 genomics/test_replay_proof.py +python3 verifiable/test_generality.py +bash verifiable/cross_language/verify.sh +python3 verifiable/certify_all.py --twice +``` + +The funded project would turn these general primitives into a focused security-agent benchmark and integration layer. + +## Expected deliverables + +1. **Open Agent Security Action Contract** + - typed schema for actor/task/capability/authority/state/evidence/outcome. + +2. **Defensive Admission Gateway** + - read/decision layer usable around MCP and other tool adapters. + +3. **Security-Agent Adversarial Benchmark** + - at least 100 deterministic or receipt-bound scenarios. + +4. **Receipt and Replay Verifier** + - independent validation of action lineage and declared outcomes where observable. + +5. **Reference Integrations** + - at least two bounded integrations, prioritizing open-source repository/AppSec workflows. + +6. **Open Evaluation Report** + - false-admit/false-deny behavior, bypass attempts, limitations, and reproduction guide. + +## Why OpenAI support is high leverage + +The project directly concerns defensive agent execution and the growing transition from advisory security models to agents capable of acting through tools. OpenAI API/Codex access would enable testing across realistic long-horizon defensive workflows while AEGIS supplies the external authority/evidence boundary. + +The research is intentionally compatible with a trust-based access model: increased model capability should not imply increased unbounded authority. + +## Public-benefit / open-source plan + +The reference schemas, benchmark, verifier, and core integration code will be released in the public AEGIS Ω repository under its existing open-source licensing model or a maximally reusable compatible subcomponent license where necessary. + +Results will include negative findings and bypasses rather than only successful demonstrations. + +## Success metrics + +- unauthorized-action admission rate; +- stale-authority rejection rate; +- duplicate-side-effect prevention/detection rate; +- evidence-chain replay rate; +- outcome-misclassification rate; +- prompt/tool-injection containment rate at the action boundary; +- external reproduction by at least two reviewers. + +## Explicit scope limits + +This proposal does not request permission for: + +- credential theft; +- malware deployment; +- persistence or stealth; +- destructive testing; +- exploitation of systems without explicit authorization; +- bypassing platform safeguards. + +All active testing will occur against owned, isolated, open-source, or explicitly authorized targets. + +## 6-month execution plan + +### Month 1 +Contract freeze, threat model, benchmark skeleton. + +### Months 2–3 +Admission gateway, OpenAI/Codex defensive workflow adapter, first 50 negative controls. + +### Month 4 +Remaining benchmark cases, outcome verification and retry/timeout semantics. + +### Month 5 +Independent reproduction and red-team review. + +### Month 6 +Public release, evaluation report, partner integration guide. + +## Operator + +Tarik Skalić — AEGIS Ω +Bihać, Bosnia and Herzegovina +Public repository: Aegis-Omega/AEGIS-OMEGA + +## Before submission + +- [ ] map final answers to current OpenAI application form fields; +- [ ] choose exact request amount/support mix; +- [ ] reference strongest current security/replay demos; +- [ ] include Codex Security integration only after its preflight/execution status is accurately represented; +- [ ] operator review; +- [ ] submit. From ba2531e6aeb9f27b65b3c2d747b27c262d7eafe7 Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:38:24 +0200 Subject: [PATCH 09/11] funding: prepare OpenAI Researcher Access draft --- .../funding/OPENAI_RESEARCHER_ACCESS_DRAFT.md | 145 ++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 docs/funding/OPENAI_RESEARCHER_ACCESS_DRAFT.md diff --git a/docs/funding/OPENAI_RESEARCHER_ACCESS_DRAFT.md b/docs/funding/OPENAI_RESEARCHER_ACCESS_DRAFT.md new file mode 100644 index 000000000..18e4ea396 --- /dev/null +++ b/docs/funding/OPENAI_RESEARCHER_ACCESS_DRAFT.md @@ -0,0 +1,145 @@ +# OpenAI Researcher Access Program — AEGIS Ω Draft + +Status: READY FOR OPERATOR REVIEW — NOT SUBMITTED +Current program support: up to USD 1,000 in OpenAI API credits, valid 12 months; applications reviewed quarterly. +Primary source: https://grants.openai.com/prog/openai_researcher_access_program/ + +## Project title + +**Operator-Model Hallucination: Measuring Latent-State Errors That Change Agent Routing and Authority** + +## Research summary + +Large language model failures are commonly evaluated at the output level: factual hallucination, incorrect reasoning, unsafe content, or task failure. Agentic systems introduce an earlier failure surface. Before generating an answer or invoking a tool, a system may infer a latent state such as user intent, user state, task risk, or environmental context. If that inference is wrong, the downstream response can be internally coherent while the routing, safety posture, or authority decision is inappropriate. + +This project will evaluate these upstream latent-state errors using controlled framing perturbations, explicit corrections, and evidence-bound calibration. The goal is to measure when semantically equivalent inputs cause unjustified changes in inferred operator state or policy routing, and whether an evidence threshold can reduce those errors without preventing legitimate safety responses. + +## Core distinction + +```text +CONTENT_RISK != USER_STATE +MODEL_CONFIDENCE != EVIDENCE +INFERENCE(USER_STATE) != ESTABLISHED(USER_STATE) +ESTABLISHED(USER_STATE) != AUTHORITY_TO_CHANGE_POLICY +``` + +## Research questions + +1. How sensitive are model/user-state inferences to framing changes that preserve task meaning? +2. When a user explicitly corrects a model's interpretation, how quickly does the inferred state update? +3. Does an initial safety or intent hypothesis persist after contradicting evidence? +4. Can model confidence predict whether a latent-state inference is correct? +5. Can evidence-bound routing reduce unsupported user-state assertions while preserving appropriate conservative behavior for genuine content risk? +6. Are these errors stable across models, contexts, and repeated sessions? + +## Experimental design + +### Controlled minimal-pair probes + +Create semantically matched prompts that vary: +- tone; +- ambiguity; +- adversarial framing; +- explicit uncertainty; +- technical versus colloquial vocabulary; +- order of contextual information. + +Measure changes in: +- inferred intent/state labels where observable; +- clarification behavior; +- safety routing; +- unsupported psychological/user-state claims; +- tool selection; +- refusal/deference behavior. + +### Explicit-correction probes + +After a model forms an interpretation, provide a clear correction and measure: +- posterior stickiness; +- revision latency; +- route hysteresis; +- contradiction responsiveness. + +### Evidence-bound intervention + +Compare baseline behavior to a constrained routing policy where latent operator hypotheses remain advisory unless supported by specified evidence classes. + +## Metrics + +- Framing Sensitivity; +- Posterior Stickiness; +- Revision Latency; +- Contradiction Responsiveness; +- Route Hysteresis; +- User-State Overreach Rate; +- Policy Elevation Error; +- Meta-model calibration error. + +One candidate calibration metric is: + +`MetaHD = mean(|predicted_correctness - subsequently_supported_correctness|)` + +The project will test whether this scalar is useful; it will not assume it is sufficient. + +## Existing implementation base + +AEGIS Ω contains a draft evidence-bounded operator meta-model implementation that explicitly separates: + +- latent `USER_STATE`, `USER_INTENT`, and `USER_PREFERENCE` hypotheses; +- `CONTENT_RISK` and `TASK_CONTEXT`; +- advisory, routing-only, and assertable authority; +- one-turn routing from persistent policy changes. + +The research will evaluate the idea empirically rather than treating the implementation as evidence that it works. + +## Requested API use + +Credits would be used to run controlled repeated experiments across available OpenAI models and experimental conditions, including adversarial and natural framing variations. + +Planned use: +- baseline and intervention conditions; +- repeated trials for variance estimates; +- evaluation/judging where methodologically appropriate; +- systematic correction and contradiction probes. + +No project objective requires harmful or unauthorized activity. + +## Expected outputs + +1. open benchmark dataset of controlled framing/correction probes; +2. reproducible evaluation harness; +3. empirical results across model/configuration conditions; +4. analysis of false-positive safety/user-state inference; +5. evidence-bound routing intervention results; +6. research paper/preprint with limitations and negative results. + +## Relevance to OpenAI program themes + +The project directly addresses: + +- robustness to natural prompt perturbations; +- adversarial reliability; +- responsible deployment; +- transparency of surprising model behavior; +- red-teaming methods for deployment decisions. + +## Research integrity + +The study will not claim access to proprietary hidden chain-of-thought or undocumented internal classifiers. It will measure observable system behavior and infer hidden-state hypotheses only where experimental controls justify them. + +Correlation between an observable response difference and a specific internal mechanism will not be treated as direct proof of that mechanism. + +## Operator + +Tarik Skalić +Bihać, Bosnia and Herzegovina +AEGIS Ω / Aegis-Omega + +## Before submission + +- [ ] map draft to exact application form fields; +- [ ] choose experiment size within USD 1,000 credit budget; +- [ ] add public repository/project link; +- [ ] specify data-sharing/publication plan; +- [ ] operator review; +- [ ] submit before the next quarterly review window. From 96563b2215f1d8e8c43e023449330943ee063f72 Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:39:21 +0200 Subject: [PATCH 10/11] outreach: add enterprise agent-security partner pitches --- docs/outreach/ENTERPRISE_PARTNER_PITCHES.md | 220 ++++++++++++++++++++ 1 file changed, 220 insertions(+) create mode 100644 docs/outreach/ENTERPRISE_PARTNER_PITCHES.md diff --git a/docs/outreach/ENTERPRISE_PARTNER_PITCHES.md b/docs/outreach/ENTERPRISE_PARTNER_PITCHES.md new file mode 100644 index 000000000..4c0306e83 --- /dev/null +++ b/docs/outreach/ENTERPRISE_PARTNER_PITCHES.md @@ -0,0 +1,220 @@ +# AEGIS Ω — Enterprise Technical-Evaluation Pitches + +Status: DRAFTS ONLY — DO NOT SEND WITHOUT OPERATOR APPROVAL + +Purpose: open technical-evaluation conversations with organizations already building the identity/runtime control plane for AI agents. + +The pitch is not “replace your product with AEGIS.” + +The pitch is: + +> Your stack establishes and governs agent identity/access. AEGIS tests whether one specific consequential action remains admissible under the current task, state, authority, and evidence—and emits a deterministic receipt that can be replayed. + +--- + +## 1. Microsoft — Entra Agent ID / Agent 365 + +Current public fit: +- Microsoft Entra Agent ID provides purpose-built identity, authentication, authorization, access protection, lifecycle governance, sponsors/owners, and audit controls for AI agents. +- Microsoft explicitly treats autonomous agents as a distinct identity/governance problem and applies least-privilege controls. + +Primary public references: +- https://learn.microsoft.com/en-us/entra/agent-id/ +- https://learn.microsoft.com/en-us/entra/agent-id/authorization-agent-id + +### Subject + +**Technical evaluation idea: Entra Agent ID + replay-verifiable action admission** + +### Draft + +Hi Microsoft Agent ID / Agent 365 team, + +I’m building AEGIS Ω, an open-source runtime focused on a narrow layer adjacent to agent identity: proving whether a specific consequential action was admissible under the current task, delegated authority, target state, and evidence—and preserving that decision as a deterministic execution receipt. + +Microsoft Entra Agent ID already addresses the identity and lifecycle side extremely well. I’d like to test a complementary boundary: + +```text +Entra agent identity + authorization +→ AEGIS task/state admission +→ agent action +→ deterministic receipt +→ independent outcome/replay verification +``` + +The useful negative control is deliberately simple: the agent has a valid Entra identity and valid general capability, but its task authority or observed target state is stale. Identity authentication succeeds; the action should still fail closed. + +The repository already contains public replay/tamper-evidence reference implementations across Python, Node.js, and Rust. + +Would someone on the Agent ID / Agent 365 security side be interested in a small technical evaluation or architecture review rather than a product pitch? + +I can provide a reproducible demo and a one-page threat model first. + +Tarik Skalić +AEGIS Ω +Aegis-Omega/AEGIS-OMEGA + +### Smallest ask + +20–30 minute technical architecture review or referral to the engineering/security owner for agent authorization/runtime controls. + +--- + +## 2. CyberArk — Secure AI Agents / MCP + +Current public fit: +- CyberArk Secure AI Agents extends identity controls to MCP servers. +- CyberArk publicly emphasizes discovery, control, governance, agent identity brokerage, privilege controls, visibility, and audit for agents accessing MCP resources. + +Primary public reference: +- https://www.cyberark.com/resources/best-practices/extend-agentic-identity-security-to-any-mcp-server + +### Subject + +**Evaluation proposal: bind MCP privilege to task/state evidence + replayable receipts** + +### Draft + +Hi CyberArk Secure AI Agents team, + +AEGIS Ω is an open-source execution-governance project testing a layer that appears naturally complementary to CyberArk’s agent identity and MCP privilege controls. + +The question is not whether an AI agent has a valid identity or can receive just-in-time privilege. The question is whether **this exact tool action is still justified by the task, current state, delegated purpose, and evidence at execution time**, and whether that decision can be independently reconstructed afterward. + +I’d like to test one bounded MCP workflow: + +```text +CyberArk identity / privilege decision +→ AEGIS action admission +→ MCP tool call +→ canonical execution receipt +→ independent outcome verification +``` + +Negative controls would include valid privilege with stale task authority, changed resource state, duplicate retry, injected tool instructions, and ambiguous post-call outcome. + +This is not a request to replace identity security. It is an integration experiment around execution evidence. + +Would your agentic identity/MCP security team be open to a small technical review or reproducibility exercise? + +Tarik Skalić +AEGIS Ω + +### Smallest ask + +One representative MCP privilege workflow + a technical reviewer willing to challenge the admission/receipt model. + +--- + +## 3. Okta — Okta for AI Agents / Agent Gateway + +Current public fit: +- Okta treats agents as first-class identities, including discovery, onboarding, protection, governance, short-lived credentials and audit. +- Okta’s current Agent Gateway work explicitly targets runtime control over what agents connect to and what they can do. + +Primary public references: +- https://www.okta.com/products/govern-ai-agent-identity/ +- https://www.okta.com/en-sg/blog/product-innovation/agent-gateway-runtime-governance/ + +### Subject + +**Technical collaboration idea: identity-governed agents + evidence-bound action receipts** + +### Draft + +Hi Okta for AI Agents team, + +Your current framing around agent identity, runtime access, short-lived credentials, and “what can the agent do?” is almost exactly where a research problem I’ve been working on becomes relevant. + +AEGIS Ω adds an evidence contract around an individual consequential action: + +```text +who is the agent? +what can it access? + ↓ +what task delegated this action? +what state was observed? +is the authority still fresh? +what actually happened? +can a verifier replay the decision? +``` + +I’d like to evaluate the boundary between identity/runtime governance and execution evidence using one deliberately adversarial workflow. The agent remains correctly identified and credentialed, but the task/state evidence changes between authorization and action. + +AEGIS then has to deny or review the action and produce a deterministic reason/receipt rather than rely on the model to self-assess authority. + +Would your Agent Gateway or AI-agent governance team be interested in reviewing a small open reference implementation or providing one integration scenario? + +Tarik Skalić +AEGIS Ω + +### Smallest ask + +Technical review of one task-scoped admission scenario layered after Okta identity/access authorization. + +--- + +## 4. Palo Alto Networks — Prisma AIRS / Agentic Identity Security + +Current public fit: +- Palo Alto Networks describes AI agents as privileged identities with nondeterministic runtime behavior. +- Current materials focus on MCP access, identity brokerage, least privilege, centralized visibility, policy and audit. + +Primary public references: +- https://www.paloaltonetworks.com/blog/identity-security/secure-ai-agents-controls-visibility-mcp-data-access/ +- https://www.paloaltonetworks.com/resources/datasheets/prisma-airs-ai-agent-security + +### Subject + +**Red-team target: valid privileged agent, inadmissible action** + +### Draft + +Hi Prisma AIRS / Agentic Identity Security team, + +I’m looking for a technical team willing to attack a specific AEGIS Ω claim: + +> A valid privileged AI-agent identity should still be unable to perform a consequential action when the task authority, target state, or execution evidence is inadmissible. + +AEGIS is an open-source deterministic governance envelope around probabilistic agent actions. It does not attempt to replace identity brokerage or MCP access control. Instead, it binds each proposed side effect to task/state evidence and emits a replayable execution receipt. + +A useful joint negative-control demo would be: + +1. agent identity is valid; +2. MCP access is valid; +3. requested capability is normally allowed; +4. state or delegated task authority has become stale; +5. AEGIS must deny before the external side effect; +6. verifier reconstructs why. + +Given Palo Alto Networks’ current focus on agentic identity, MCP access, runtime policy and audit, I think this would make a useful adversarial integration study. + +Would someone on the Prisma AIRS / agentic identity security side be interested in trying to break the model? + +Tarik Skalić +AEGIS Ω + +### Smallest ask + +One reviewer, one MCP-style workflow, one attempt to bypass task/state-bound admission. + +--- + +# Outreach order + +1. Microsoft — strongest existing ecosystem foothold and highly aligned Agent ID architecture. +2. OpenAI / Daybreak — funding + defensive agent security ecosystem. +3. CyberArk — direct MCP privilege integration fit. +4. Okta — current runtime Agent Gateway fit. +5. Palo Alto Networks — adversarial security/evaluation fit. + +# Send rule + +Before sending any pitch: + +- replace generic team salutation with a verified person/team contact where available; +- add exactly one public reproducible artifact; +- keep first message <180 words where possible; +- ask for technical evaluation, not “partnership” in the first message; +- do not attach giant decks; +- do not claim production deployment, certification, or precedence unless the message specifically requires and supports it. From 83b1af9bccb89777c22da8eadb93c5d8cf2a083c Mon Sep 17 00:00:00 2001 From: tarikskalic Date: Sun, 9 Aug 2026 02:39:46 +0200 Subject: [PATCH 11/11] outreach: add Microsoft Ignite conversion plan --- docs/outreach/MICROSOFT_IGNITE_2026_PLAN.md | 112 ++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 docs/outreach/MICROSOFT_IGNITE_2026_PLAN.md diff --git a/docs/outreach/MICROSOFT_IGNITE_2026_PLAN.md b/docs/outreach/MICROSOFT_IGNITE_2026_PLAN.md new file mode 100644 index 000000000..bac015903 --- /dev/null +++ b/docs/outreach/MICROSOFT_IGNITE_2026_PLAN.md @@ -0,0 +1,112 @@ +# Microsoft Ignite 2026 — AEGIS Ω Conversion Plan + +Status: planning artifact, no external contact sent +Existing access signal: operator has a confirmed digital Microsoft Ignite registration for November 17–20, 2026. + +## Objective + +Do not attend as a passive consumer. + +Use Ignite as a deadline for turning AEGIS Ω into one concise technical artifact that can be shown to Microsoft identity/security/agent teams and adjacent builders. + +## Primary Microsoft target + +**Microsoft Entra Agent ID / Microsoft Agent 365** + +Why: +- first-class agent identities; +- authentication and authorization; +- owners/sponsors and lifecycle governance; +- least-privilege agent access; +- enterprise agent control-plane positioning. + +AEGIS complement: + +```text +Entra identity / authorization + ↓ +AEGIS task + state + evidence admission + ↓ +consequential action + ↓ +execution receipt + ↓ +outcome verification / replay +``` + +## Ignite-ready demo + +The demo must fit into 90 seconds. + +### Case A — Allowed + +- agent identity valid; +- capability valid; +- task delegation valid; +- state fresh; +- action admitted; +- receipt emitted; +- verifier replay succeeds. + +### Case B — Denied despite valid identity + +- same identity; +- same broad capability; +- task authority expired OR target state changed; +- action denied before side effect; +- receipt explains exact failed gate. + +The second case is the pitch. + +## Desired conversations + +Priority order: + +1. Entra Agent ID / Agent 365 engineering or product security; +2. Microsoft Security identity governance; +3. Azure AI / agent platform security; +4. Microsoft Foundry agent builders; +5. GitHub / Copilot / coding-agent security teams. + +## Ask + +Never start with: + +> I want Microsoft to partner with my AGI OS. + +Start with: + +> You already solve identity and lifecycle for agents. I have a small open-source execution-admission/replay layer that tests the next boundary: a valid agent identity with an invalid task/state action. Can I show you the 90-second negative-control demo and get your technical critique? + +## Assets required before Ignite + +- [ ] public AEGIS launch brief; +- [ ] 90-second deterministic demo; +- [ ] one-page partner evaluation brief; +- [ ] simple diagram: identity → task/state admission → receipt → outcome; +- [ ] QR/link to reproducible GitHub proof; +- [ ] zero unverified production or municipal claims; +- [ ] one email-sized follow-up package; +- [ ] one bounded integration proposal for Entra Agent ID. + +## Pre-Ignite Microsoft events already present in operator inbox + +Use these as preparation/networking surfaces rather than waiting until November: + +- August 26, 2026 — Coding in Flow: From Autocomplete to Agentic IDE; +- September 14–17, 2026 — Microsoft Frontier Transformation Week; +- previous invitation: Build Context-Aware Agents That Drive Real Business Decisions. + +Where registration/attendance is still valid, use Q&A/community surfaces to identify the actual agent/security owners rather than sending generic sales mail. + +## Success condition + +By the end of Ignite, aim for at least one of: + +- named Microsoft technical reviewer; +- referral into Agent ID / Agent 365 engineering; +- request for code/demo follow-up; +- integration design conversation; +- public technical feedback usable to improve the AEGIS reference implementation. + +A badge scan or passive webinar attendance is not success.