Software Products & Security Labs

AuthorityLab

Deterministic analysis of authority changes for AI agents defined in repositories.

In short

AuthorityLab is a security research and product development project. It is designed to analyse which authority an AI agent configured inside a repository holds, how that authority shifts when the configuration changes, and whether a change should be allowed, modified or blocked. The project is in its validation phase.

Starting point

AI agents are increasingly configured through files in the repository: hooks, scripts, commands, MCP servers. A small change can quietly give an agent more authority than intended, for example through delegation or by bypassing an existing boundary. These shifts are hard to spot because they spread across several files and layers.

My role

Personal research and development project: concept, decision model, architecture and validation planning.

Solution

The planned deterministic decision core is intended to compare the authority state before and after a change (Transitive Authority Regression Check) and produce a traceable result: ALLOW, MODIFY or BLOCK. Unknown elements should be treated neither as safe nor as critical by default; they should be reported explicitly as UNKNOWN. Each decision is intended to include explainable, auditable evidence.

ALLOW, MODIFY or BLOCK?

A small learning example: pick a configuration change and see how the decision core classifies it. Static, nothing is executed.

Choose a change

ALLOW · Allowed

No new authority: read access stays within the already permitted area.

  • ALLOW – Allowed
  • MODIFY – Adjust
  • BLOCK – Block
  • UNKNOWN – Unknown

Technologies

  • Node.js
  • CLI
  • CI-Integration
  • Web GUI
  • JavaScript
  • Security Research

Key functionality

  • Transitive Authority Regression Check across repository configuration
  • Deterministic decision core with ALLOW / MODIFY / BLOCK semantics
  • Explicit UNKNOWN class instead of silent assumptions
  • Detection of delegation and bypass of existing boundaries
  • Explainable, auditable evidence for each decision
  • Planned local and CI-friendly command line interface
  • Concept for a thin web GUI with sanitised report history

Security & performance

  • Candidate commands, hooks, scripts or MCP servers are never executed; the analysis is purely static
  • Secret values are neither read nor stored
  • Reports are sanitised before they are displayed

Outcome

  • Defined decision model with documented semantics
  • Documented architecture and validation plan for a CLI and web interface

A hosted product, runtime enforcement, attestation, pilot customers or commercial validation are not complete and are not claimed here.