BoundaryGuard

BoundaryGuard — Public Authority Evaluator demonstrating deterministic agent permission checks.
Deterministic DENY: an out-of-scope change is rejected with reason outside_delegated_scope.
Real GitLab CI pipeline FAILED after detecting an authority violation.
Corrected Merge Request passes GitLab CI with an authorised authority decision.
Authority ALLOW after a human/operator-executed correction restored the permitted scope.
Live smoke verification: index, assets, authorised example and unauthorised example — all PASS.
Public GitLab Pages demonstrator showing the BoundaryGuard Authority Evaluator interface.
Isolated GitLab Pages validation pipeline completed successfully, including deployment, smoke checks and audit.
Authentic GitLab Duo advisory analysis of MR !4, with limited diff context. No autonomous remediation.
Separate historical GitLab Duo Human-in-the-Loop checkpoint demonstration.

Inspiration

AI agents are increasingly capable of reviewing code, proposing fixes, running tests, and participating in software delivery. But as agents become more autonomous, a fundamental question emerges:

Who verifies that an AI agent actually has the authority to perform the action it is about to take?

Traditional CI/CD pipelines answer questions such as "Does the code work?" and "Did the tests pass?" They do not necessarily establish whether the actor proposing or executing a change was authorised to do so.

BoundaryGuard was inspired by this gap between technical correctness and legitimate authority.

Building on our earlier open-source authority-boundary work, we set out to bring deterministic authority verification into GitLab-based DevSecOps workflows.

Our guiding principle became:

Agents reason. CI proves. Authority engine decides.

BoundaryGuard is not another AI chatbot or conventional security scanner. It addresses a distinct problem: ensuring that increasingly capable software agents operate within verifiable boundaries of authority.

What it does

BoundaryGuard is an authority-aware verification system for agent-assisted software delivery.

It evaluates whether proposed changes and operations remain within explicitly delegated permissions, producing deterministic ALLOW or DENY decisions, clear reason codes, and auditable evidence.

The system distinguishes seven important concepts:

Agent proposal — what an agent recommends or requests.
Human review — examination of the proposed operation.
Authenticated approval — a decision attributable to an authorised identity.
Execution authorisation — separate permission to perform a specific action.
Actual execution actor — the identity responsible for performing the operation.
Deterministic CI checks — reproducible verification of authority and policy conditions.
Independent verification — an additional trust boundary when independently established.

These distinctions prevent an agent's recommendation from automatically becoming permission to act.

Real GitLab demonstration: DENY → GREEN

We demonstrated BoundaryGuard through an authentic GitLab Merge Request.

An intentionally out-of-scope change triggered:

Authority decision: DENY
Reason: outside_delegated_scope
Result: Failed GitLab CI pipeline

The violation involved a file outside the permitted delegated scope.

After a human/operator-executed correction, the subsequent verification produced:

Authority decision: ALLOW
Reason: authorized
Result: Successful GitLab CI pipeline

This demonstrates an enforceable authority boundary rather than a warning generated by an AI model.

Importantly, the correction was executed by a human/operator, not autonomously by GitLab Duo.

GitLab Duo and Human-in-the-Loop evidence

BoundaryGuard also incorporates authentic GitLab Duo experimentation:

A genuine advisory analysis session associated with a Merge Request.
A separate historical Human-in-the-Loop checkpoint demonstration.

These are distinct recorded sessions, not a single integrated autonomous remediation workflow.

Public demonstrator and live verification

A publicly accessible static Authority Evaluator demonstrates the core permission-checking concept.

An isolated GitLab Pages deployment was also verified through four successful live smoke checks:

index_available — PASS
assets_available — PASS
authorised_example_allows — PASS
unauthorised_example_denies — PASS

The checks establish HTTP availability and expected demonstrator behaviour. They do not independently prove the exact deployed revision.

How we built it

BoundaryGuard combines a deterministic JavaScript authority-verification core with GitLab-native development, CI/CD automation, agent-assisted analysis, and structured evidence.

Technology stack

JavaScript / Node.js: Deterministic authority evaluation, policy checks, and automated testing.
GitLab: Source control, Merge Requests, pipeline history, and auditable development evidence.
GitLab CI/CD: Automated tests, authority gates, release verification, staging checks, and audit evidence generation.
GitLab Duo Agent Platform: Authentic advisory agent analysis and separate supervised-workflow experimentation.
GitLab Pages: Public static demonstrator and isolated staging deployment.
JSON evidence artifacts: Structured, machine-readable authority decisions and verification results.
GitLab APIs: Authenticated inspection of pipeline status, job results, permissions, and execution evidence.

Architecture

The architecture follows three principles.

1. Agents reason.

AI agents can analyse code, investigate potential problems, and recommend actions. Their recommendations do not automatically confer authority.

2. CI proves.

Deterministic checks evaluate declared permissions, permitted changes, policy constraints, and expected system behaviour.

Failures produce explicit evidence and prevent successful verification.

3. Authority engine decides.

Authorisation outcomes depend on defined constraints rather than the confidence or natural-language reasoning of an AI model.

Development process

We built the project incrementally, beginning with authority decisions and expanding into GitLab CI/CD integration, structured evidence, release verification, and deployment checks.

The implementation includes:

Deterministic ALLOW/DENY decisions.
Explicit authority scopes and reason codes.
Fail-closed verification behaviour.
Automated regression tests.
GitLab Merge Request authority checks.
Structured CI evidence artifacts.
Release-verification checks.
Bounded staging-readiness retries.
Request and response timeouts.
Sanitised diagnostic and evidence URLs.
Isolated Pages deployment without replacing the existing public demonstrator.

Testing and deployment

The complete local test suite passed:

387 tests passed, 0 failed, 0 skipped.

The published smoke-fix branch subsequently completed all four of its GitLab CI jobs successfully.

A separate isolated live-validation pipeline completed successfully, including:

Automated testing.
Pages build.
Release verification.
GitLab Pages staging publication.
Live staging smoke verification.
Audit evidence generation.

All four live smoke checks passed.

Challenges we ran into

Separating agent reasoning from execution authority

The central challenge was ensuring that an AI agent's ability to propose or perform an operation would not be confused with permission to execute it.

We addressed this through deterministic authority decisions and explicit separation between proposals, approvals, execution mandates, and actual actors.

Demonstrating real authority enforcement

A simulated DENY result would not convincingly establish that BoundaryGuard could enforce restrictions in an actual delivery workflow.

We therefore created a real GitLab Merge Request containing an out-of-scope change.

The authority job rejected it, and the pipeline failed.

After a controlled human/operator correction, the authority decision changed to ALLOW and the corrected pipeline succeeded.

Both outcomes are preserved in authentic GitLab evidence.

GitLab Duo privilege boundaries

We investigated custom GitLab Duo workflows and the effective permissions available for agent execution.

A platform-level permission limitation prevented us from establishing the required restricted privilege ceiling for safe custom-flow invocation.

Rather than granting excessive authority or relying on restrictive prompts as a substitute for enforceable permissions, we deliberately avoided unsafe execution.

As a result, the project does not claim to have demonstrated one fully integrated autonomous supervised-remediation session.

GitLab Pages deployment timing

We encountered uncertainty around publication readiness, pipeline scheduling, and propagation of the resolved GitLab Pages URL.

We addressed these challenges with:

Dotenv-based URL propagation.
Corrected CI stage ordering.
A shared 60-second readiness deadline.
Per-request and response-body timeouts.
Bounded retries for transient failures.
Named failure diagnostics.
Fail-closed verification outcomes.

We subsequently validated these improvements through a real isolated Pages deployment and successful live smoke checks.

Preserving authentic evidence

We carefully distinguished:

Agent proposals from executed actions.
Historical demonstrations from current verification.
Human/operator corrections from autonomous agent remediation.
CI success from independent verification.
HTTP availability from deployed-revision identity.

This discipline was essential to keeping the project technically credible and its evidence independently inspectable.

Accomplishments that we're proud of

1. Authentic DENY → GREEN enforcement

BoundaryGuard rejected an out-of-scope change in a real GitLab Merge Request.

The original pipeline failed with outside_delegated_scope. Following a human/operator-executed correction, the authority decision became ALLOW and the corrected pipeline succeeded.

2. 387 passing automated tests

The complete local test suite passed with zero failures, demonstrating extensive regression coverage across the implemented behaviour.

3. Successful GitLab CI/CD integration

Automated GitLab pipelines executed tests, builds, release verification, authority checks, and audit-related jobs.

The successful results are preserved in GitLab's pipeline history.

4. Genuine live deployment verification

An isolated GitLab Pages deployment completed successfully without overwriting the existing public demonstrator.

The live smoke job passed all four checks covering availability and authorised/unauthorised example behaviour.

5. Auditable authority evidence

BoundaryGuard generates structured evidence explaining authority decisions, verification results, and relevant execution context.

6. Meaningful GitLab Duo experimentation

We obtained authentic agent advisory analysis and separate Human-in-the-Loop demonstration evidence while preserving the distinction between those sessions.

7. Security boundaries preserved

We deliberately avoided weakening authority policies, bypassing permission restrictions, or manufacturing successful results.

For BoundaryGuard, a trustworthy DENY is just as important as a successful ALLOW.

What we learned

The most important lesson was simple:

An agent's ability to perform an action is not the same as its authority to perform that action.

We also learned that:

Deterministic verification is essential when AI-generated recommendations have operational consequences.
Human approval and execution authorisation are different responsibilities.
The identity of the actor performing an operation matters as much as the operation itself.
A successful pipeline does not automatically prove that an action was authorised.
GitLab CI/CD evidence becomes more valuable when decisions and failure reasons are explicit.
Deployment verification requires careful handling of timing, retries, and stale content.
Security boundaries must be enforced by technical controls, not merely by instructions to AI agents.
Honest documentation of limitations strengthens confidence in the results.

Above all, we learned that trustworthy agentic automation requires a clear relationship between intent, authority, action, and evidence.

What's next for BoundaryGuard

BoundaryGuard establishes a practical foundation for authority-aware agent-assisted software delivery.

Our next priorities are:

1. Integrated supervised agent workflows

Connect agent analysis, genuine Human-in-the-Loop approval, and authorised continuation within one verifiable workflow when appropriate permission enforcement becomes available.

2. Independent verification

Introduce a separately trusted verification boundary capable of validating evidence without depending solely on the actor being evaluated.

3. Stronger deployment provenance

Bind deployment evidence to the exact served revision rather than relying only on contextual commit identifiers and HTTP availability checks.

4. Broader authority-policy coverage

Extend verification to additional GitLab operations, agent roles, resources, and deployment permissions.

5. Reusable DevSecOps integration

Develop reusable authority-checking components that other teams can integrate into their agent-assisted delivery pipelines.

Our long-term vision is to make authority verification a standard part of software delivery involving autonomous and semi-autonomous agents.

Traditional CI asks:

"Does the software work?"

BoundaryGuard adds another essential question:

"Was the actor authorised to perform this action — and can we prove it?"