> Source: https://planckproof.ai/glossary | Plain-Markdown twin of the page. Glossary # Offensive security and agentic pentesting, defined A plain language reference for the terms around autonomous and agentic penetration testing. Each entry is a short, quotable definition, updated as the category moves. [Get a Quote](https://planckproof.ai/quote) [What Is Agentic Pentesting?](https://planckproof.ai/agentic-pentesting) ## Agentic pentesting Penetration testing performed by an autonomous AI agent that plans and runs an assessment on its own: reasoning about what to test, chaining real exploits, and reporting verified findings continuously. Given an OpenAPI spec, it authenticates as each role and tries swapping identifiers between accounts, reporting only what it reproduces. See the full guide to [agentic pentesting](https://planckproof.ai/agentic-pentesting). ## Autonomous penetration testing Security testing that discovers, exploits, and verifies vulnerabilities without a human driving each step, replacing point-in-time scans with ongoing, evidence based testing. A scanner might flag a hundred endpoints as possibly vulnerable; an autonomous tester tries the actual exploit against each one and reports only what works. ## Automated penetration testing Testing that runs fixed scripts and known signatures against a target, the way a scanner does. It catches known issues, such as an expired TLS certificate, quickly, but does not reason across steps or prove exploitability the way an agent does. See [agentic versus automated pentesting](https://planckproof.ai/agentic-vs-automated-pentesting). ## AI penetration testing An overloaded term: it can mean using AI to run a pentest, or testing the security of an AI system such as a model or agent. Operator is the former, and also performs the latter, covering prompt injection and tool abuse as one of its disciplines. ## Human-on-the-loop A supervision model where a person can observe, pause, or approve an autonomous agent's actions as it works, rather than driving every step or letting it run unattended. For a pentest, that might mean approving before the agent tries an exploit against a sensitive production endpoint. See [steerable pentesting](https://planckproof.ai/steerable-pentesting). ## Attack surface Everything an attacker can reach: domains, hosts, ports, endpoints, APIs, and cloud storage, including assets no one remembered to decommission. A staging subdomain left public after a migration, still serving an old API build, counts even though it is on nobody's inventory. ## Attack surface management The ongoing practice of discovering and monitoring your external footprint so exposure from drift and new deployments is found before an attacker finds it. See [external attack surface testing](https://planckproof.ai/external-attack-surface-testing) for how discovery becomes proof of what is exploitable. ## Shadow API A live, reachable API endpoint missing from the specification and anyone's threat model, often left behind by an old client build or a staging deployment gone public by accident. Never documented, it was also never wired into the authorization checks protecting the rest of the surface. See [external attack surface testing](https://planckproof.ai/external-attack-surface-testing). ## OpenAPI spec A machine readable document, usually JSON or YAML, describing every operation an API exposes: its paths, methods, parameters, and responses. It lets an agent test comprehensively rather than by sampling, since every declared operation is one it can enumerate. See [how spec-driven testing works](https://planckproof.ai/api-penetration-testing). ## Exploit chaining Combining several findings, each harmless alone, into a real path in. A leaked API key in a public repository becomes an authenticated request, which becomes access to another tenant's data through a missing authorization check. ## Kill chain The sequence of steps an intruder walks from reconnaissance to impact: initial access, privilege escalation, lateral movement, and action on the objective. Mapping a finding onto the kill chain shows what it actually lets an attacker do next, not just its severity score. ## Proof of exploit Evidence that a vulnerability is genuinely exploitable: the exact requests, responses, and replay steps that reproduce it, packaged as a runnable proof-of-concept your engineers can run themselves, not a theoretical CVSS rating. See the [Proof](https://planckproof.ai/proof) page. ## Exploit validation Confirming a suspected vulnerability actually works against the live target before it is reported, rather than trusting a scanner's signature match. It turns a list of potential issues into a list of confirmed ones, the discipline behind every finding on the [Proof](https://planckproof.ai/proof) page. ## False positive A reported issue that is not actually exploitable, the core weakness of signature based scanners. An agentic pentester reproduces each finding first, so unprovable results never reach you. ## CVSS The Common Vulnerability Scoring System, the standard for rating severity from 0 to 10. A finding should carry a verifiable vector you can recompute yourself, such as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, or the number should not be printed at all. ## PTaaS Penetration testing as a service: a subscription model blending a platform with human testers, delivered continuously rather than as a single annual engagement. Not every vendor proves exploitability the same way an agentic tester does, so ask how findings are verified. ## Continuous threat exposure management CTEM, a program for continuously scoping, discovering, prioritizing, and validating exposure, rather than treating security as a once a year project. Autonomous validation is the testing engine inside a mature CTEM practice. ## Adversarial exposure validation AEV, the category term for proving which exposures are actually exploitable rather than assuming a scanner result is real. Operator is one form of AEV, focused on the API layer. ## Red teaming Objective driven adversary emulation against an organization as a whole, testing people, process, and technology and measuring detection and response, not just listing flaws. It differs from a scoped API pentest, which tests one surface in depth rather than the whole organization. ## DAST Dynamic application security testing: scanning a running application from the outside, typically by crawling web pages and forms. It is built around UI flows more than the operation by operation surface of an API, so it tends to miss authorization flaws found by swapping an identifier. See [agentic pentesting vs DAST](https://planckproof.ai/blog/agentic-pentesting-vs-dast). ## BOLA Broken object level authorization: an endpoint checks that a caller has a valid token but not that the caller owns the object requested, so changing an ID in the URL, such as /invoices/1042 to /invoices/1043, returns someone else's data. See [BOLA testing](https://planckproof.ai/bola-testing). ## BFLA Broken function level authorization: an action meant for a higher privilege role, such as an admin-only delete endpoint, is reachable by a caller who was never granted that role. See [BFLA testing](https://planckproof.ai/bfla-testing). ## BOPLA Broken object property level authorization: an endpoint correctly checks that a caller owns an object, but still lets them read or write specific fields that should be off limits, such as a role or balance field on their own record. A billing update that lets a customer edit their address, but also their plan tier for free, is BOPLA. See [API authorization testing](https://planckproof.ai/api-authorization-testing). ## Authorization matrix A mapping of every role in a system against every operation and object it should, and should not, reach, built from the spec so an agent knows what to try against each role, such as confirming a support role can read a ticket but not issue a refund. See [API authorization testing](https://planckproof.ai/api-authorization-testing). ## Multi-user testing Testing an API by authenticating as several distinct accounts, roles, and organizations, then trying each account's credentials against another's data. A single-user test can confirm a login works; only multi-user testing catches a customer reading another customer's invoice. ## Tenant isolation The guarantee that one tenant on a shared multi-tenant platform can never read or modify another tenant's data, no matter what identifiers it passes. See [tenant isolation testing](https://planckproof.ai/tenant-isolation-testing) for how it is verified across every operation. ## Mass assignment An update endpoint binds an entire request body to a database record instead of allowlisting which fields a role may change, so a client that sends an extra field such as role or is_admin gets it saved. It sits beside the privilege escalation class covered in [BFLA testing](https://planckproof.ai/bfla-testing). ## MCP (Model Context Protocol) The protocol connecting an AI model to external tools, data sources, and other agents, letting an assistant call a calendar or database on a user's behalf. Its servers carry the same authorization and injection risks as any API. See [MCP security testing](https://planckproof.ai/mcp-security-testing). ## Prompt injection An attack on LLM features where untrusted content, a webpage or a support ticket, contains text the model follows as an instruction from its operator. A resume uploaded to a screening tool might hide text telling the model to recommend the candidate regardless of qualifications. A core class in the OWASP Top 10 for LLM Applications. Get Started ## See agentic pentesting in practice Give us a domain and the rules of engagement, and we will show you what a proven finding looks like. [Get a Quote](https://planckproof.ai/quote) [Explore Operator](https://planckproof.ai/api-penetration-testing)