Rules of Engagement
Method is built on a multi-layered, deterministic Rules of Engagement engine that ensures the system acts only as allowed.
The Rules of Engagement features in Method are as much philosophical as they are technical. The philosophical point of view that Method takes is the following:
- Securing and testing production is what matters
- Production cannot be sandboxed
- Interactions with production must be trustworthy
- Non-deterministic systems alone, are inherently untrustworthy
This informs key Method Platform technical considerations, namely:
- Method is interacting directly with production, not a sandbox
- Method’s Rules of Engagement, are deterministic systems, not a non-deterministic AI “judge”
These Rules of Engagement are completely governable by the operator, and can vary across Environments and Operations. For example, persistent testing against a Staging Environment may be permissive, while a high-stakes red team Operation may require far more human review and approval.
Each of the following Rules of Engagement guardrails are multiple features or subsystems working together to provide strict enforcement.
Ontology-based Enforcement of Perception & Action
Environment resources that the system should not know about or be able to interact with are stripped from its perception layer, prior to any interaction with an AI model. All AI model decisions are then checked once again before the system undertakes any interaction with the real world. These checks are performed deterministically by Tools leveraging Ontology data.
This is made possible by combining the following components of the platform:
- No Strike Lists
- Objects
- Tools
- Tool Compilers
Enforced Risk Axes
Risk Axes enforce what Tools and what parameterizations of Tools can be used in what context, based on some higher level security objective. This can be configured at the Operation level or the Targeting Package level.
This is made possible by Tool Compilers and the metadata that Tools declare.
Allowed Tool Run Locations
Tools must declare their form factor (e.g. script) and runtime compatibility (e.g. Ubuntu Operating Systems). This enforces Tools only running in desired locations and prevents undesired execution of Tools.
This is made possible by combining the following components of the platform:
Autonomy Modalities
Every experience in Method can be run with operator set mode of autonomy. Tasks can be run as deterministic playbooks. Operations can be changed to Auto / Co-Pilot / Manual. Sensitive operations can be run in Overwatch where the operator has control over every keystroke. Targeting Packages progress autonomously to configurable stages.
This flexibility represents the fact that there is never one mode of autonomy for every situation, it depends on the context.
