Rules of engagement
Autonomy, in writing.
AigentX runs without step-by-step human direction. It does not run without rules. This page sets out those rules, so you can evaluate them before an assessment rather than after one.
Before an assessment starts
What you define.
- Scope
- The applications, domains, services, APIs, networks and environments authorized for testing. AigentX does not operate outside declared scope.
- Identities & roles
- The accounts and roles AigentX may authenticate as. Supplying more than one lets it test the authorization boundaries between them.
- Exclusions
- Specific endpoints, third-party systems, sensitive functions or workflows removed from the assessment.
- Testing level
- How far AigentX may go, set per environment. Defined below.
- Context
- Business or technical background: recent changes, sensitive workflows, architecture notes, areas of concern.
Testing levels
How far it may go.
Passive
Observation and non-mutating requests. Reads application state; does not create, modify or delete data.
Suitable for production systems where any state change is unacceptable.
Active
DefaultExploitation attempts against authorized targets, including creating the application state a test requires. Does not perform deliberately destructive actions.
The default for most engagements, including production, where change is bounded and reversible.
Destructive
By written authorizationPermits testing that may disrupt service or damage data: resource exhaustion, deletion paths, denial-of-service conditions.
Requires explicit written authorization and is normally restricted to non-production environments.
Inside the boundaries you set
How it limits itself.
Scope, identities, exclusions and testing level are yours. These are the limits AigentX applies to its own execution inside them.
- Proving, not pushing
- Once a vulnerability and its impact are proven, AigentX stops. It exploits only to the minimum extent a proof of concept requires.
- Existing data
- AigentX avoids unnecessary modification or deletion of data that is already there. Where a test must manipulate state to validate an authorization boundary, it can work against data it creates itself rather than changing yours.
- Availability
- Service availability is protected unless the testing level explicitly authorizes destructive testing.
- Internal policy
- Any action that exceeds AigentX's internal safety policy is blocked, whatever the engagement otherwise permits.
- Human review
- In the Managed model, KomodoSec penetration testers review and validate the findings before delivery.
Deployment
Where it runs from.
- Internet-facing
- No customer-side deployment. AigentX reaches the target directly.
- Internal
- A lightweight Linux jump host inside your environment initiates an outbound connection to AigentX. No inbound connection into your network is required.
- Platform
- SaaS on AWS.
- Management access
- Protected by two-factor authentication.