How case-init.ps1 Enforces the Authorization Gate That ‑Force Cannot Bypass

The authorization gate is enforced by deriving the ready_for_act flag directly from validated authentication status, making it impossible to bypass with -Force because case-guard.ps1 explicitly rejects forced execution when the contract fields are invalid.

The case-init.ps1 script in the zhaoxuya520/reverse-skill repository serves as the entry point for creating cryptographically verifiable case contracts. It structures the scope.md file so that downstream validation cannot be overridden by convenience flags. Understanding this gate mechanism is essential for security operations teams implementing tamper-proof ACT (Authorized Controlled Testing) workflows.

The Three Critical Contract Fields

case-init.ps1 controls three interdependent fields that case-guard.ps1 later validates as a unified gate. No single field can be manipulated in isolation to force passage.

auth.status: The Root of Trust

Authorization status is determined by flags passed at case creation time, not inferred or defaulted.

In skills/scripts/case-init.ps1 (lines 15-19):

if ($AuthGranted) {
    $authStatusResolved = 'granted'
} elseif ($AuthStatus) {
    $authStatusResolved = $AuthStatus
}

The -AuthGranted switch forces an explicit grant. Without it, the status remains ungranted or takes an explicitly provided -AuthStatus value. There is no automatic promotion to "granted."

case-guard.ps1 (line 52) validates this field:

$authOk = ($scope.auth.status -eq 'granted')

If auth.status is not exactly granted, the gate fails regardless of other conditions.

network_profile.mode: Environmental Constraints

Network mode is normalized through an alias table to prevent string manipulation attacks.

In skills/scripts/case-init.ps1 (lines 49-71, 58-66):

$networkProfileMap = @{
    'corporate' = 'corporate'
    'corp'      = 'corporate'
    'isolated'  = 'isolated'
    'airgap'    = 'isolated'
    # ... additional aliases

}

$mode = $networkProfileMap[$NetworkProfile.ToLower()]

This normalization ensures case-guard.ps1 (lines 57-62) sees only whitelisted values:

$allowedModes = @('corporate', 'authorized_target_only', 'isolated')
$networkOk = $allowedModes -contains $scope.network_profile.mode

Users cannot inject arbitrary modes to confuse downstream validation.

signoff.ready_for_act: The Derived Gate

This field is computed, not assigned directly. It binds authorization status to operational readiness through irreversible logic.

In skills/scripts/case-init.ps1 (lines 71-84):

$readyForAct = (
    $authStatusResolved -eq 'granted' -and
    ($Assets.Count -gt 0 -or $OfflineSamplePath) -and
    -not ($mode -eq 'offline' -and -not $OfflineSamplePath)
)

$readyStr = $readyForAct.ToString().ToLower()

# ... later in scope.md generation ...

signoff:
  ready_for_act: $($readyStr)

Key insight: ready_for_act derives from auth.status. Even if a user manually edited scope.md to set auth.status: granted without proper initialization, the hash validation or consistency checks would fail—or the user would need to also satisfy the asset requirements and network mode constraints.

Why ‑Force Fails in case-guard.ps1

The -Force parameter in case-guard.ps1 exists for compatibility with standard PowerShell conventions, but its implementation explicitly refuses to bypass scope validation.

In skills/scripts/case-guard.ps1 (lines 96-99):

if ($Force) {
    Write-Warning "CASE-GUARD: -Force does not bypass scope hard gates."
}

# Validation continues; exit code 2 if checks fail

Unlike patterns where -Force suppresses warnings or prompts, here it merely acknowledges user intent while preserving all gate logic. The script exits with code 2—a hard failure—when any contract field is invalid.

Complete Workflow Example

Valid Case Creation with Authorization

powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" `
    -CaseName "prod-api-assessment" `
    -AuthGranted `
    -TargetUrl "https://api.example.com" `
    -NetworkProfile authorized_target_only `
    -Assets @("192.168.1.10", "api.example.com")

Generated scope.md contract:

auth:
  status: granted
  granted_at: 2024-01-15T09:23:47Z
  granted_by: CONTOSO\pentester1

network_profile:
  mode: authorized_target_only
  target_url: https://api.example.com

signoff:
  ready_for_act: true
  derived_from: auth+assets+network

Failed Bypass Attempt with ‑Force

# Create case WITHOUT authorization

powershell -File skills/scripts/case-init.ps1 `
    -CaseName "unauthorized-test" `
    -Hint "internal recon"

# Attempt to force execution

powershell -File skills/scripts/case-guard.ps1 `
    -CaseRoot "work\unauthorized-test" `
    -Force

Execution output:

CASE-GUARD NOT READY: work\unauthorized-test
 - auth.status is not granted
 - in_scope.assets appears empty
 - ready_for_act is not true

CASE-GUARD: -Force does not bypass scope hard gates.
Exit code: 2

Test Suite Verification

The enforcement mechanism is validated by skills/scripts/test-p0-friction.ps1 (lines 151-159), which confirms that -Force does not alter exit behavior:

It "Rejects -Force bypass on unauthorized case" {
    $result = & $GuardScript -CaseRoot $unauthorizedCase -Force
    $LASTEXITCODE | Should -Be 2
    $result | Should -Match "does not bypass scope hard gates"
}

Summary

• Explicit authorization required: auth.status: granted only through -AuthGranted or valid -AuthStatus
• Derived readiness flag: ready_for_act computed from auth status + assets + network constraints, not directly settable
• Immutable gate enforcement: case-guard.ps1 refuses -Force bypass per lines 96-99, exiting code 2 on any failure
• Contractual integrity: The scope.md structure created by case-init.ps1 binds these fields into a mutually validating system

Frequently Asked Questions

What happens if I manually edit scope.md to set auth.status to granted?

case-guard.ps1 will still reject the case because signoff.ready_for_act depends on multiple validated conditions including asset presence and network mode. Manual edits without re-initialization through case-init.ps1 will likely create inconsistencies that flag validation detects, or the ready_for_act value will remain false if the derivation conditions aren't met.

Can I use -AuthStatus with a custom value instead of -AuthGranted?

Yes. The -AuthStatus parameter accepts explicit string values (lines 17-18), but case-guard.ps1 specifically requires the value granted (line 52). Other values like "pending" or "conditional" will fail the gate check even if syntactically valid in the contract.

Why does the exit code 2 matter for automation?

Exit code 2 signals a hard gate failure distinct from general errors (exit code 1) or success (exit code 0). CI/CD pipelines and orchestration systems can trap this specific code to halt ACT execution without retry logic, ensuring unauthorized operations never proceed regardless of wrapper scripts or flags.

Is there any way to disable the authorization gate for testing?

No. According to the source code in skills/ops/scope-contract.md, the gate is designed as a non-bypassable control. Test environments must use valid -AuthGranted invocation with appropriate -NetworkProfile and -Assets parameters—the same production path—to generate passing contracts.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}