RINP // CYBERSECURITY SERVICES
Resource CenterDid I understandthis concept correctly?
We explain, in a shared language, the cybersecurity concepts used across Red in Pulse services, technical reports, and executive summaries. The definitions make the scope and output of offensive security work clear from the client's perspective, and they also show the distinctions between commonly confused terms.
Canonical definitions of commonly confused concepts
Abuse Path
A genuinely exploitable behavior sequence in the runtime chain of a generative-AI application: indirect prompt injection, RAG disclosure, tool abuse, MCP authorization abuse and multi-turn chained exploitation are typical steps of this chain. It is not a theoretical vulnerability list; it is proven with a safe proof of concept (PoC) under controlled execution, shown in the field. It is the AI counterpart of the attack path in traditional penetration testing and carries the same epistemological claim: not 'it can be done' but 'it was done'. This distinction is especially important in AI security, because the field is full of speculative threat narratives; it is easy to say a model 'could be abused', but showing that the abuse produces a concrete result through the real tools and authority bound to the model takes evidence. OWASP LLM Top 10 and MITRE ATLAS frame the steps of this path. The abuse path is the primary evidence object of the Generative AI Red Team.
attack path - the Modular Red Team Simulation goes to the critical target; this chain tests the AI application’s behavior.
AI-assisted Offensive Workflow
The use of human-supervised AI by the penetration-test and Red Team team across discovery, hypothesis generation, evidence handling, reporting and re-test flows; it is the backbone of the AI for Pentest & Red Team service. Separating two common misunderstandings from the start clarifies the concept. First: this is not a test sold to an external customer but an internal leverage that raises the team's own productivity; AI here is a tool, not a product. Second and more important: this is not a fully autonomous attack agent. The concept's entire design draws a deliberate boundary between itself and the fear of 'AI running an attack on its own'. AI takes on the speed-providing side: it scans thousands of log lines, generates hypotheses about likely attack paths, accelerates repetitive evidence-handling tasks, prepares report drafts. But the decision and the responsibility are always carried by a human; the approval model and human-in-the-loop gates stand in front of every step that touches the target. This distinction is both a legal and an ethical necessity: the consequences of a step taken in a penetration test can be borne by an authorized expert, not by software. Observability makes every step of the process accountable. AI generates hypotheses, the human decides.
The Generative AI Red Team is the customer product being tested; this service is the internal workflow being improved. They are not the same.
Anonymized Case
A case-narrative form in which a real customer engagement is de-identified while its structure, evidence-object type and decision impact are preserved. In offensive security, sharing references is caught between two pressures: showing how an engagement runs builds trust, yet customer confidentiality and usually a contractual secrecy obligation forbid disclosure. Anonymization is the discipline that resolves this tension; it is not fabrication, because it derives no scenario from scratch and only neutralizes traceable detail (organization name, individuals, unique configuration, numeric scale). The sector category is named generically, quantitative data is turned into qualitative phrasing, and the instructive skeleton of the engagement is left intact. What is read is therefore not a case but a method: what was done stays visible while to whom it was done becomes invisible.
“success story” - Red in Pulse cases are decision-clarity stories, not success or dramatic-threat narratives.
Approval Model
The written structure defining who approves each step of an AI-assisted workflow, at which authority level and with which acceptance logic; it covers the use scenario, rules of engagement, artefact access, action level, proof-of-concept acceptance and controlled-pilot acceptance gates. Human-in-the-loop is a principle, and the approval model is that principle's working mechanism; one says 'the decision must stay with a human', the other answers 'which decision, with which human, at which threshold'. This distinction is decisive in practice, because if authority is unclear, automation turns into a risk rather than speed: a flow everyone can approve and a flow no one approves carry the same danger. The approval model divides authority across steps; reconnaissance and hypothesis generation may be low-threshold, while an action that touches the target or is irreversible requires a high-authority, documented approval. Together with observability, it is the core of the structure that separates AI use from the fear of a 'fully autonomous attack agent' and makes it accountable.
AI for Pentest & Red Team.
Assumed Breach
A scenario that begins with the assumption that the attacker has already reached the internal network or an identity, and from there validates lateral movement and the impact chain toward the critical target. The third module of the Modular Red Team Simulation (RT-3) works with this logic. The concept represents a mature shift of mindset in security thinking. The traditional approach spent all its energy defending the perimeter, that is, on the attacker never being able to get in; the implicit assumption of this approach was that a breach is a preventable event. Modern threat reality refuted this assumption: a determined enough attacker, against a large enough attack surface, sooner or later finds a way. Assumed breach accepts this reality not as a confession of weakness but as a design principle and changes the question: instead of 'how do I prevent getting in', it asks 'once in, how far can one advance'. This shift carries the test's energy from the initial-access stage, which takes hours of effort, to where the real value is, the spread inside. Initial access is accepted as a hypothesis, and the real matter becomes where microsegmentation, narrowing effective permissions and detection capability stop the attacker.
Modular Red Team Simulation.
Attack Path
The path to the critical target along the threat-actor, critical-asset or assumed-breach axis, under controlled execution, reduced to an evidence package with technical traces, a timeline and reproducible steps. It is the primary evidence object of the Modular Red Team Simulation. The weight of the concept hides in where the emphasis falls: what matters is not the destination but the path itself. Announcing a vulnerability's existence is a discovery; starting from that vulnerability, combining it with other weaknesses, escalating privilege and moving laterally to walk all the way to critical-target impact is proof. This distinction matters because none of the individual vulnerabilities may carry high severity, yet combined they can produce a business-stopping outcome; the attack path makes exactly this compound effect visible. It is not the same as a vulnerability chain or a kill chain; it travels to the end of those conceptual chains, to concrete business impact, and frames each step with MITRE ATT&CK. The chain-breaking control then shows at which link of this path a single correct intervention would render the whole chain inert.
chainable access flaw - the Network Security Penetration Test looks at the exposure chain; the attack path goes all the way to critical-target impact.
Attestation (Evidence Claim)
Signing and verifying build and CI pipeline outputs (model artefact, data-provenance chain, dependencies) and recording evidence claims in a structured form. The point is not that a file exists but the portable, verifiable proof of where it came from, which process it passed through and who approved it. What software supply-chain attacks (such as SolarWinds and XZ Utils) make plain is this: the legitimacy of an artefact reaching production must rest on evidence, not on a trust assumption about its source. The release decision (promote/rollback) is tied to this evidence ground; without the claim the decision has nothing to stand on. Sigstore, Cosign, in-toto and the SLSA framework are the established field forms of this chain; attestation is the signed, machine-verifiable form of provenance.
AI Model Supply-Chain Assurance.
Audit-ready Evidence Package
A package presentable in a defensible form before management, an independent auditor or a regulator, carrying the technical-validation summary, control mapping, executive summary, prioritized remediation plan and closure evidence as a single whole. The output of a security engagement often becomes useless at audit time, because the technical report has not been translated into the auditor's language and the bridge between 'what was found' and 'which requirement was met' is missing. This package builds that bridge in advance: it maps findings to the control items of frameworks such as ISO 27001, SOC 2 or OWASP ASVS, so the auditor can verify the evidence against their own checklist. It is not the same as portable assurance for a customer security review; it is a separate assurance line (S4-B). The difference is in the counterpart: portable assurance tells the customer 'you can trust us', while the audit-ready package tells the auditor 'the requirement is met, here is independently verifiable proof'.
Evidence package.
Blast Radius
The total area of impact reachable from a single starting position. What sets a finding's priority is often not the finding itself but how far one can travel from it; of two vulnerabilities with the same severity, one may sit in an isolated corner while the other is the door to the critical target. The concept shifts the defense's focus from a single vulnerability score to access topology: the question becomes not 'how serious is this' but 'from here, where can one go'. Shrinking this radius is the shared aim of zero-trust architecture, microsegmentation and narrowing effective permissions; each limits the business impact of a single finding by narrowing the area a breach can spread into. The blast radius is the design measure that turns the assumption 'a breach will happen' into the question 'how far will it spread when it does'.
Validating segmentation through real access paths.
BOLA / BFLA
Two core authorization flaws in API security. BOLA (Broken Object Level Authorization) is a horizontal authority violation: accessing another same-level user's object. BFLA (Broken Function Level Authorization) is a vertical authority violation: invoking an administrative function that should be unreachable. Both sit at the top of the OWASP API Security Top 10 (API1 and API5), and their root cause is shared: an authenticated request is assumed to be authorized. Yet authentication knows the identity, while authorization asks whether that identity has a right over this very object or function; at the API layer this second check, though it must be performed at every object access, is often skipped. In multi-tenant architectures the most expensive form of BOLA is the collapse of the customer boundary, and these findings surface not through an automated scanner but through manual validation that follows the business logic.
Application Security Penetration Test (API scope).
Canary Evidence
A traceable, harmless object placed into an environment on purpose to show that a control is actually enforced (for example a decoy credential, a marked document or a trap record). The most common fallacy in security is the gap between 'the policy is written' and 'the policy works'; a control being defined does not mean it fires in the field. Canary evidence closes this gap: rather than seeing that a control exists, it proves its decision is applied with an object designed to leave a trace when touched. It is used in the live validation of controls such as data-loss prevention (DLP), access monitoring or detection rules. Removing it from the environment at the end of the test and leaving no operational impact is a requirement of the side-effect control principle of controlled execution.
Modular Red Team Simulation.
Chain-breaking Control
A set of control proposals showing, in an owned and ordered way, which control breaks which step on the attack path, reduced to a fix-verify work list. It is not a list of individual 'patch suggestions'; it is a structural control decision that breaks the chain of the attack path and forms the execution leg of the Modular Red Team Simulation report. The concept's logic is economical and offers a strong lever to the defense. An attack path is by nature many steps: it consists of links such as initial access, credential gathering, privilege escalation, lateral movement and reaching the critical target. The intuitive reaction is to try to close all these links at once, but this is both expensive and often impossible. The chain-breaking control proposes a different logic: a chain breaks not at its weakest but at its most strategic link. A single control placed at the right link renders inert all the following steps bound to that link; if the attacker must pass through that step to reach the critical target, cutting that step closes the whole path. So the matter is not to close every vulnerability one by one but to see the attack path as a whole and find which single intervention breaks the most of the chain at once. The detection-gap matrix shows which steps are invisible, and the chain-breaking control which step must be closed.
Modular Red Team Simulation.
Client Security Review
A security-posture assessment (vendor security assessment) an organization undergoes from its customers when evaluated as a solution partner or supplier. Standard question pools such as SIG, CAIQ and VSAQ are common forms of this review. It is the trigger of the portable-assurance line (S4-A): when a customer asks 'why should we trust you, why should we entrust our data to you', the answer must be not a marketing claim but an auditable evidence package. The strategic weight of this concept comes from turning security from a cost center into a sales condition. As supply-chain risks grow, organizations now question not only their own security but the security of every supplier they work with; failing a security review means not a technical shortfall but a lost deal. So assurance is now a concern not only of the security team but of the commercial line as well. It is not the same as the audit-ready evidence package (S4-B); one tells the customer 'you can trust us', the other tells the auditor 'the legal requirement is met'.
S4-A portable assurance + the Customer Security-Review FAQ.
Component List (BOM / AI-ML-BOM)
A verifiable component list for model artefacts, data sources, dependencies and build outputs. Called SBOM (Software Bill of Materials) for traditional software and AI-ML-BOM in the AI context; CycloneDX and SPDX are its structured, machine-readable record forms. Its necessity arises from the fact that most modern systems are assembled from inherited components: the source of a risk is often not in the code an organization wrote but in the library it inherited, the pre-trained model or the dataset. It is therefore not an inventory table but an evidence object; it answers not 'what is inside' but 'when a vulnerability is disclosed, am I affected, and to whom can I defend this'. As it matures it combines with provenance and attestation to form the inventory leg of supply-chain trust.
AI Model Supply-Chain Assurance.
Conditional Access
A policy layer that, after authentication, allows access, demands further verification or denies it based on device compliance, location, application and risk signals. It is one of the strongest controls of modern identity security, but its strength and its weakness lie in the same place, its coverage: the policy governs only the requests it evaluates; a client, flow or protocol it does not evaluate can proceed without ever engaging it. The attacker therefore often does not try to break the policy but looks for the path the policy does not see. Typical examples are legacy authentication protocols that can bypass modern conditional-access checks, or unexpected entry surfaces such as the device code flow. This asymmetry forces an important conclusion: the existence of conditional access is not an assurance; what must be tested is whether the policy covers all entry paths, that is, the completeness of its coverage. And that is understood not by reading a configuration list but by controlled testing, by trying whether it can actually be bypassed.
Cloud Security Penetration Test.
Continuous Penetration Testing
An offensive assurance program of at least three months, managed with planned monthly validation sprints and a fix-verify cycle. It is neither a one-off test nor an unlimited service; it is a planned rhythm within package limits. The concept's rationale arises from the mismatch between the traditional annual penetration test and modern development pace. An application now changes not once a year but many times a week or a day; each deployment can bring a new vulnerability. A test done once a year gives a photograph of the day it was done, but that photograph begins aging the moment it is taken, and a blind span forms across the eleven months until the next test. Continuous Penetration Testing closes this blind span: it takes security out of being an event and turns it into a process. Two things form its backbone: measurable closure, that is, tracking found vulnerabilities not to the point of being found and left but to verifiable closure, and monthly management visibility. What separates it from a one-off test is the time axis; each month the security posture turns into a trend line and the mean time to remediate (MTTR) into a performance indicator.
The Application Security Penetration Test (PT-1) is one-off deep validation; Continuous Penetration Testing is not its “continuous version”.
Controlled Testing
The principle that no attack simulation is performed without written authority, explicit scope, Rules of Engagement (RoE), a test window, approval gates, human oversight, side-effect control and an escalation line being visible. This is the ground on which Red in Pulse produces defensible assurance and the precondition of every offensive service. What separates an offensive engagement from a real attack is not a difference in the techniques used; the techniques are often the same. What separates them is the frame: the same action, done within written authority and an agreed scope, is a legitimate assurance engagement, and done outside it, a crime. So soft phrases like 'ethical hacking' or 'safe testing' do not stand in for controlled testing; because what makes a test legitimate is not good intent but a frame that is written and auditable. Good intent is not evidence in a court or an audit; a signed scope, a test window and an escalation record are. NIST SP 800-115 and PTES are the methodological frameworks of this discipline; controlled testing is their applied form in the field.
Controlled execution and Rules of Engagement.
Cookie Tossing and Shadowing
Setting a domain-wide cookie from a controlled subdomain to overwrite the application's own value (fixation) or to have a second cookie with the same name delivered alongside it (shadowing). The crux is that the HTTP protocol does not firmly define which of several same-named cookies is chosen; the parser on the server side makes this decision by its own rule, and these rules differ across server software. The attacker exploits this ambiguity: while the application processes the value it believes is 'correct', it is in fact processing the one the attacker planted. Session fixation, session confusion or authorization bypass can follow from here. It grows stronger combined with the related-domain attacker position (compromise of a subdomain sharing the same eTLD+1); the most robust defense is using the __Host- prefix on critical cookies.
Application Security Penetration Test.
Crown Jewel (Critical Target)
A critical data asset, privileged identity or business-process component tied directly to the organization's business objective, whose compromise by an attacker produces a high-business-impact outcome. The traditional approach dissipates attention trying to protect every asset; the critical-target concept instead prioritizes the defense and focuses the test. It is the starting parameter of Objective-Based Red Team scenarios (RT-2) and the destination of lateral movement in the Assumed Breach Simulation (RT-3). What counts as a critical target is not a technical decision but a business one: the question 'what, if lost, stops the business; which data, if leaked, collapses reputation or compliance' is answered together with management. An offensive engagement run without this definition produces findings but cannot prioritize them. 'Critical target' is preferred in Turkish copy.
Modular Red Team Simulation (RT-2 / RT-3).
Customer Boundary
The authorization boundary separating one customer's data from another's in a multi-tenant application. This is the core trust promise of modern SaaS architecture: hundreds of customers sharing the same infrastructure, database and application code can never see one another's data. But this boundary is logical, not physical; it depends on the code making the right decision on every request. The critical fallacy is believing that authentication establishes this boundary on its own; yet authentication knows who the user is, not whether that user has a right to this very record. The second check, authorization, must be performed separately at every object access; skipped once, an authenticated user can reach into another customer's data. The most expensive form of the BOLA (Broken Object Level Authorization) flaw arises right here: a single missing authority check can collapse the entire customer isolation, among the gravest findings possible in a multi-tenant product. So the customer boundary is tested not with an automated scanner but with manual validation that follows the business logic.
Testing the API authorization boundary in real user flows.
Defensible Assurance
A form of assurance that is portable under third-party or audit pressure, audit-ready and resting on an evidence-based ground. It is not a claim of 'total assurance' or 'one hundred percent security'; on the contrary, it is a mature stance that accepts such a claim is impossible. It works on two distinct lines: portable assurance (S4-A), for customers and business partners; audit-ready assurance (S4-B), for auditors and regulators. At the center of the concept stands the weight the word 'defensible' carries. Most security claims are built on rhetoric: 'our systems are secure', 'we follow best practices'. Such a claim cannot be stood behind when questioned, because its basis is a discourse. Defensible assurance, by contrast, is built on the assumption that the claim will be questioned: when a customer, an auditor or a court says 'prove it', the answer is an evidence package; a ground produced under controlled execution, resting on evidence-based validation, independently examinable. So it is a fixed part of the Red in Pulse category line; every output the firm produces is designed against the test 'can it be stood behind when questioned'.
All offensive-assurance services.
Deployment Pipeline
The path of taking the model from the registry to the deployment environment; it covers recording in a verifiable way the trust chain of staging-versus-production, multi-tenant, multi-region or shared-platform topology. It is the last link of the model trust chain, and this position makes it especially critical. All the earlier links of a model's supply chain, the training data, the build pipeline, the approval in the registry, may have been carefully secured; provenance may be proven, attestation signed, the SLSA level high. But all this trust is tested once more as the model is taken to production. If the deployment pipeline is insecure, even the best-validated model can be altered at the moment of deployment, that is, at the point where trust is most relaxed; the attacker targets not the head of the chain but precisely its end. So the assessment asks these questions: is the artefact validated in staging the same as the one going to production, who can intervene in the deployment process, can one customer's deployment affect another on a multi-tenant platform, and is integrity preserved in a rollback. The trust produced with provenance and attestation carries meaning only if it is preserved in this final step too.
AI Model Supply-Chain Assurance.
Detect-and-report Reflex
An employee's reflex to notice a social-engineering attempt and report it to the organization; it is the primary evidence object of the Social Engineering Simulation. Human-layer measurement was long locked onto the wrong question: 'how many clicked?' Yet what saves an organization in a real incident is not that no one clicked; in a large enough organization someone eventually does. What saves it is how fast the person who clicked or grew suspicious reports the situation. The detect-and-report reflex measures this second ability and shifts the center of measurement from blaming the individual to assessing the organization's defensive reflex. The click rate is in this frame only context data; the decision object is how many sounded the alarm and how quickly. It is read together with time-to-report and the correct-escalation percentage. The frame is deliberately reflex-building, not blaming; the aim is not to catch an employee but to turn the organization into an early-warning system.
“who got fooled?” language - the Red in Pulse Social Engineering Simulation does not use a shaming frame.
Detection Gap
A MITRE ATT&CK-aligned, measurable control-visibility matrix for the SOC and Blue Team, showing where attack-path steps are seen and where they are missed by the defense. It is not a list of individual missing detection rules; it is structured evidence of defensive visibility along the attack path. The most valuable output of a red team engagement is not the attack path it found but the map of where the defense stayed blind along that path. Because an attack path can be closed, but the real question is whether the defense will be able to see a similar attack in the future. The detection-gap matrix answers this question step by step: for each step of the attack it asks 'did this behavior produce a log, trigger an alarm, did the SOC notice it', and lays out the seen and unseen steps as a map. Its value is in turning the red team's finding into the blue team's to-do list; each blind spot is given together with a concrete control proposal that would close that gap. So the engagement does not merely say 'the attack succeeded' but 'it stayed invisible at this step and can be made visible with this control'. It is directly connected to the chain-breaking control concept.
Attack path and detection visibility.
Device Code Flow (Device Authorization Grant)
An OAuth 2.0 flow (RFC 8628) designed for devices with limited keyboard or browser interaction (smart TVs, consoles, CLI tools), where the user approves a code on a separate device. Its legitimate purpose is useful, but its value to an attacker lies in this asymmetry: the flow carries no attacker-owned link, so it never triggers the 'do not click the suspicious link' reflex organizations have trained for years. The user approves a genuine code on a familiar, real sign-in screen; yet the session approved belongs to the attacker. Because this technique bypasses the link-based detection controls of phishing, it is assessed as a separate entry surface in initial-access scenarios; its defense is built by bringing this flow within conditional-access policy coverage and by monitoring device-code requests.
Modular Red Team Simulation.
Dual-Layer Delivery
Reporting delivered together as two distinct layers: a decision-support summary for management (risk picture, priority rationale, closure visibility) and an owned, ordered, fix-first work list for the technical team. The classic failure of security reports is being written for a single counterpart: a purely technical report becomes a document management does not read, while a purely executive summary becomes one the team cannot act on. Dual-layer delivery closes this rupture; the two layers must be visible at the same time and rest on the same validated findings, because one answers 'why it matters' and the other 'exactly what to do'. The absence of either layer makes the report either unreadable or unactionable; the value lies in translating the same reality into two languages at once.
All offensive-assurance services.
Dwell Time
The time between an attacker entering the environment and being noticed. It is considered the most honest measure of detection capability, because it tells not how many security products an organization has deployed but how long those products take to catch a real attack; the number of tools in the inventory is an investment indicator, dwell time an outcome indicator. The weight of this metric comes from this reality: in modern breaches the real harm accumulates not in the initial access but across the time the attacker spends unnoticed; the longer they stay invisible, the more lateral movement they make, the more identities they gather, and the closer they come to the critical target. But a lab assumption or a vendor brochure cannot show this duration; it is understood only by measuring it in a real scenario, in an engagement run without the defense's knowledge. The Modular Red Team Simulation and the assumed-breach scenario take this duration out of being an estimate and turn it into a measured fact; the detection-gap matrix then shows step by step why the duration stretched.
Attack path and detection visibility.
Effective Permissions
The gap between an identity's permissions defined on paper and the real access that remains after those permissions intersect with policies, boundaries and conditions. In cloud environments what an identity can reach cannot be understood by reading the single policy attached to it, because real access arises from computing permission policies, permission boundaries, service control policies and condition expressions all together. AWS, Azure and GCP each evaluate this intersection by different rules, and the result is often broader than the administrator expects. The space between is where both excess privilege and mistaken trust assumptions hide: a role believed to be 'read only' can, combined with another policy, become write authority. Effective permissions are therefore found not by reading a configuration but by computing it; they are the starting point of privilege-chain and transitive-privilege analysis and the real question of cloud IAM assessments.
Reading cloud authority chains by access impact.
EPSS (Exploit Prediction Scoring System)
A probability-based scoring system (maintained by FIRST) that estimates how likely a vulnerability is to be exploited in the wild in the near term, based on observed exploitation data. The classic impasse of patch prioritization is this: thousands of flaws, limited resources and the impossibility of closing them all at once. CVSS, which measures technical severity, does not resolve this impasse alone, because how serious a vulnerability is is a separate question from whether it will actually be exploited. A high-severity finding never exploited in the field and a medium-severity one that is widely exploited do not carry the same urgency. EPSS answers precisely this second question, 'how likely'; CVSS answers 'how bad'. Read together, the patch queue shifts from theoretical severity to real risk, and limited resources are directed first to the vulnerabilities actively exploited in the field.
Application Security Penetration Test.
Escalation
Starting an information flow through a predefined channel to named owners when the previously agreed scope is exceeded during testing, an unexpected critical finding is encountered, or operational-impact risk arises. It is kept in writing within the Rules of Engagement (RoE) and is an inseparable part of controlled execution. The most fragile moments of a penetration test or red team engagement are the moments of departure from plan; if the decision on what to do then is improvised, the test loses its defensibility. The escalation line brings this decision forward: when a critical finding is reached, who is informed, in what order and with what authority is written in advance. Its function is not to slow things down but to make the surprise manageable; a well-designed escalation both protects the customer's operation and lets the test proceed without spoiling its evidential value. What makes a test 'controlled' is exactly this pre-decided reflex.
Controlled execution and Rules of Engagement.
Evaluation Set (Eval Set)
A structured set of test scenarios, verifiable metrics and acceptance gates designed to test an AI-assisted workflow against acceptance criteria for accuracy, security and delivery quality. The point where generative AI most resists engineering discipline is evaluation; the impression that 'it looks good' is subjective, non-reproducible and non-scalable. The evaluation set turns that impression into measurable thresholds: the same scenarios are re-run on every version, output is scored against defined metrics, and no proof of concept or controlled pilot is accepted until a threshold is cleared. In the AI-Assisted Offensive Workflow it is this set that decides with which quality assurance a tool is taken to production; together with the approval model, it is the decision mechanism that draws the line between 'it seems to work' and 'it measurably cleared the threshold'.
AI for Pentest & Red Team.
Evidence-based Validation
A validation approach derived not from a scan or audit checklist but from real technical or operational observation, measurement, chain or control effect. It is a fixed part of the Red in Pulse category line and the common criterion of all services. The essence of the distinction is this: a scanner's 'high risk' label is a claim, while the safe proof of concept (PoC) that shows the risk is genuinely exploitable is evidence. The distance between the two is the very noise that automated security tools' false positives and context-free severity scores create in the industry. Evidence-based validation filters this noise: a finding is counted as 'validated' only when it is shown in the field, within the previously agreed scope, and without destructive side effects. PTES, NIST SP 800-115 and the OWASP testing methodologies are the established frameworks of this discipline. Without this ground, nothing is called validated; because the only currency of defensible assurance is not a claim but evidence that can be independently reproduced.
All offensive-assurance services.
Fix-first Backlog
An ordered, owned, actionable remediation work list by business impact and risk level; the primary evidence object of the Application Security Penetration Test. Most security reports deliver a heap of findings and leave prioritization to the reader; yet a hundred-finding list is a burden for the product team if it does not say which work comes first, and a decision if it does. The fix-first backlog draws this line: it derives each finding from proven technical reality, ties it to an owner, and phrases it so it can enter the sprint queue directly. Its difference lies in the ordering; which vulnerability is closed first is set not by the finding's raw severity but by weighing together the harm it would do to the business if left open and the cost of the fix. Mapped to frameworks such as OWASP ASVS, the list answers not only 'what to do' but also 'which requirement it satisfies'. Its Turkish equivalent is the prioritized remediation work list.
Application Security Penetration Test.
GenAI Red Team
Testing the runtime chain of generative-AI applications (prompt, tool, data, authority, Model Context Protocol) through a validated abuse path. It is not an AI-adapted version of a traditional penetration test; it changes the question. Where classic security testing asks 'can I fool the model into a wrong answer', the GenAI Red Team asks 'can I make the model abuse the tools and authority placed in its hands'. Because in a modern AI application the risk is no longer a sentence completed wrongly but the exploitation of the tools bound to the model (database queries, email sending, file access). OWASP LLM Top 10 and MITRE ATLAS are the framework references of this area; indirect prompt injection, RAG disclosure, tool abuse and MCP authority abuse are typical steps. Generative AI Red Team is its canonical name, and its primary evidence object is the abuse path shown in the field with a safe proof of concept.
Model Supply-Chain Assurance (the model’s origin) and AI for Pentest (the internal workflow). The three are different services.
Host-only Cookie and the __Host- Prefix
A cookie with no Domain attribute is sent only to its own host and does not leak to sibling subdomains; this is a host-only cookie. The __Host- prefix makes this guarantee mandatory at the browser level: in a cookie whose name begins with this prefix it forbids Domain outright, requires the Secure flag and forces Path to be root (/). The matter is not theoretical but one of an architectural trust boundary: the real protection against cookie tossing and the related-domain attacker position must rest not on the developer remembering the right attributes on every cookie but on the browser refusing a wrong definition from the start. Security left to human attention is eventually skipped once; security enforced by the browser holds on every request. So on critical cookies such as the session identifier, the __Host- prefix is the most robust control that prevents the cookie from being overwritten or shadowed even if the attacker seizes a subdomain sharing the same registrable domain (eTLD+1).
Application Security Penetration Test.
Human in the Loop
Binding an automated flow to a human decision before it takes a consequential step. In AI-assisted offensive workflows it is the mandatory gate standing in front of every step that touches the target. The aim is not to slow things down but to lock irreversible action behind human approval; the agent may do reconnaissance, generate hypotheses and process evidence, but a human pulls the trigger. This distinction is the line that separates AI-assisted offensive work from the fear of a 'fully autonomous attack agent', and it arises from a practical reality of responsibility: the legal, contractual and operational consequences of a step taken in a penetration test can be borne by an authorized human, not by software. Human-in-the-loop left as an abstract principle is inert; together with the approval model it becomes a working mechanism defining who approves which step with what authority. Observability makes visible what happens behind this gate; the three together build the structure that makes automation accountable.
AI for Pentest & Red Team.
IAM (Identity and Access Management)
IAM, Identity and Access Management, is the control domain for the question of who can access what, under which conditions, on cloud providers. AWS IAM roles and policies, Azure Entra ID and GCP service accounts are established forms of this domain. The weight of this concept comes from a historical shift in the attack surface: traditional security protected the network perimeter, where the inside was safe and the outside dangerous. With cloud and remote work that perimeter dissolved; what now determines access to a resource is not position on the network but the authority carried by an identity. So the modern attacker's real target is not breaching a firewall but seizing a valid identity or exploiting a weakly configured permission. IAM is therefore not a side heading but the main battleground of cloud security; concepts such as effective permissions, the privilege chain and non-human identity all operate within this domain. As an established English acronym, it is preserved in Turkish copy.
Cloud Security Penetration Test.
Indirect Prompt Injection
An instruction planted in third-party content the model reads (a document, web page, email or knowledge-base record) being processed as though it were the user's request. Where it parts from direct injection makes the threat invisible: the attacker never talks to the model but writes to a source the model trusts, and waits. As the model reads that source it mistakes the embedded instruction for a command rather than data; the root cause is that the language model reads data and instruction through the same channel and cannot cleanly separate the two. It is among the most critical risks in the OWASP LLM Top 10 (within LLM01) and is not a standalone vulnerability but a link in a chain. Combined with the lethal trifecta, that is, when the model can both reach private data and communicate outward, indirect injection turns directly into data exfiltration. This is why in the Generative AI Red Team it is proven not as an isolated finding but as a step in an abuse path.
Prompt, tool and authority chain in agents.
KVKK
Law No. 6698 on the Protection of Personal Data; the core legislation regulating the processing of personal data in Turkiye. Its Article 3 definitions (data controller, data subject, explicit consent, personal data) and the Article 10 disclosure obligation form the ground for both a website's privacy notice and assurance-line design. From the offensive-security side, KVKK is not a legal detail outside the technical work but a constraint that must be designed into it. A social-engineering simulation processes employee data; a penetration test may touch personal data in production; each such contact is a processing activity and requires the written frame of controlled execution to be aligned with KVKK obligations. The practical consequence is clear: when the test scope is set, which personal data will be seen, how it will be stored, how it will be destroyed at the end of the test, and on what legal basis it will be processed are all decided in advance. Compliance is not a note appended to the end of the report but part of the Rules of Engagement (RoE); it works conceptually in parallel with the GDPR.
Compliance mapping matrix.
Lateral Movement
The attacker advancing from the first position reached toward the critical target through side steps on the network or identity plane. The Assumed Breach Simulation (RT-3) aims precisely to prove this chain: initial access is taken as given, and the real question becomes not 'how do you get in' but 'once inside, how far can you travel toward the critical target'. This emphasis rests on the anatomy of modern breaches; the real harm often accumulates not at the moment of initial access but across the quiet advance that follows. The attacker gathers credentials from a seized endpoint, moves to neighboring systems, escalates privilege and approaches the critical target step by step; MITRE ATT&CK classifies these behaviors at the tactic and technique level. Microsegmentation and narrowing effective permissions exist to make this movement harder; the test's job is to show that those controls hold not on paper but in traffic, and to measure a control's worth by where it stops the attacker. 'Yatay geçiş' is preferred in Turkish copy, with the established technical form named in parentheses.
Validating segmentation through real access paths.
Lateral Movement (Turkish)
The Turkish equivalent of the attacker advancing through side steps from the first position reached toward the critical target; the established technical form is also referred to as 'lateral movement'. It is the backbone of Assumed Breach Simulation reporting. Its technical significance comes from an understanding of where a modern breach actually does its harm: the real damage often accumulates not at the moment of initial access but across the quiet advance that follows. An attacker infiltrating a single endpoint is on its own a limited event; gathering credentials from that endpoint, moving to neighboring systems and advancing step by step to the critical target by escalating privilege is a disaster. What determines the difference between the two is how freely the attacker can move inside. This understanding has a practical consequence for defense: a control's worth is often measured not by stopping the attacker at the door, that is, at entry, but by preventing their spread after entry. Microsegmentation makes this spread harder on the network plane, narrowing effective permissions on the identity plane; the red team engagement proves in the field whether those controls actually hold. MITRE ATT&CK frames these behaviors at the tactic and technique level.
Validating segmentation through real access paths.
Lethal Trifecta
The condition where an AI system simultaneously holds three capabilities: being able to reach private data, read untrusted content, and communicate outward. Each capability is legitimate on its own and often necessary; the danger arises from the three being present together. When this condition holds, indirect prompt injection turns directly into data exfiltration, and the mechanism is strikingly simple: the attacker writes a hidden instruction into untrusted content the model will read (an email, a web page, a document); as the model reads that content it mistakes the instruction for a command, gathers the private data it can reach, and sends it to the attacker through the outward communication channel. The analytic power of the concept is in reducing a complex threat to three clear conditions and turning the defense into a design decision. The defense logic is plain: removing any one of the three breaks the chain. Let the model not reach private data, or not process untrusted content, or not communicate freely outward. So when an AI application's architecture is designed, the question to ask becomes 'which of the three capabilities can I give up'; granting all three at once is a designed-in risk.
Generative AI Red Team.
Management Visibility
Decision-support offensive-assurance visibility built for management through a monthly executive summary, quarterly risk trend, closure rate and the next month's priority area; it is the management leg of the Continuous Penetration Test. It is not an 'executive report' alone; it is the programmatic, that is, regularly repeated over time, form of two-layer delivery. The problem the concept solves is the chronic disconnect between security work and management decision. The technical team finds and closes vulnerabilities with intense effort, but this effort often has no visible counterpart at the management level; management cannot find a concrete answer to 'is security good or bad', because what reaches it is either an unreadable technical report or nothing. Management visibility closes this gap and turns security into a trend management can track, compare and decide on. Thanks to this visibility an executive can answer 'has our risk fallen since last quarter, how long do critical findings take to close, where should I allocate resources next month'. Its aim is to take security work out of being a technical activity and turn it into a business metric, that is, a manageable process; the mean time to remediate (MTTR) and the closure rate are the decision metrics of this visibility.
Continuous Penetration Testing.
MCP (Model Context Protocol)
An open protocol for establishing a standard, two-way connection between AI models and external tools, data sources and systems. Its significance comes from an architectural threshold: MCP gives the model not just information but the capacity to act; the model is no longer a passive component producing an answer to a question but an actor that can touch external systems, run queries, read files and trigger operations. This transformation brings a new attack surface along with capability. In the Generative AI Red Team scope the MCP chain, that is, authorization, user consent, token management, session control and tool exposure, is assessed as a separate abuse surface. The typical risk is this: when the authority boundary of a tool bound to the model is drawn too wide, a model hijacked through indirect prompt injection can perform a real action through that tool. So the vulnerability is not in the model itself but at the boundary of the authority given to it. The OWASP LLM Top 10 heading on excessive agent autonomy frames this risk; the abuse path often passes through here.
Generative AI Red Team.
Microsegmentation
An approach that brings network isolation down to the host, workload or application level, defining narrow neighborhoods instead of broad trust zones. Traditional network design rested on a few large zones (for example 'internal network' and 'DMZ'); an attacker entering a zone could move freely across all of it. Microsegmentation breaks these broad areas apart to shrink the area lateral movement can reach, that is, the blast radius; it is the network leg of zero-trust architecture. But the critical point is this: a segmentation policy being defined does not mean it is enforced. The boundary drawn on paper and the one that actually holds in traffic are often not the same; a rule may be written too broadly, an exception forgotten, or a path never closed. So its worth is verified by controlled testing, especially in an assumed-breach scenario: the attacker is placed in a segment and where they can move from there is measured. A control's real worth emerges from exactly where it stops the attacker.
Network Security Penetration Test.
MITRE ATLAS
A knowledge base classifying attack tactics and techniques against AI systems; the extension of MITRE ATT&CK logic to AI (ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems). It is used in Generative AI Red Team reporting to frame abuse-path steps. Its value is in setting a common language, which is especially critical in a new and fast-changing threat area. Since AI security does not yet have an established vocabulary, a finding can easily stay 'an interesting problem we don't know what to do with'. Naming an attack step with an ATLAS technique places that finding on a documented map the defense team recognizes, with countermeasures already discussed; the abuse path thus stops being a narrative and becomes an actionable reference. What ATT&CK is for traditional systems, ATLAS is for AI systems, and the two are often used together in reporting.
Generative AI Red Team.
MITRE ATT&CK
The industry's established knowledge base classifying attacker behavior at the tactic and technique level (Adversarial Tactics, Techniques, and Common Knowledge). It arranges behaviors observed from real attacks into a matrix: each tactic represents a goal (for example initial access, privilege escalation, lateral movement), each technique a concrete way of reaching that goal. In Modular Red Team Simulation reports, attack-path steps and the detection-gap matrix are presented aligned with this framework. Its function is to be a common language, and this is the most valuable bridge between the red team and the blue team: labeling an attack step with an ATT&CK technique ties the red team's finding directly to the blue team's defensive setup, SIEM rules and detection capabilities. Without this alignment a red team report stays a narrative hard to turn into defense; with it, each step becomes the question 'do we see this technique, and if not, with which control will we'. Its counterpart for AI systems is MITRE ATLAS.
Modular Red Team Simulation.
ML-BOM (AI-ML-BOM)
A component list for AI and machine-learning systems; the extension of the traditional SBOM (Software Bill of Materials) to cover the model artefact, dataset and training dependencies. Standards such as CycloneDX define a structured, machine-readable record form for ML components. Its necessity arises because an AI model's risk surface differs from traditional software: a model's security lies not only in the code that runs it but also in what data it was trained on, which pre-trained base model it inherited, and which libraries the training process depended on. A poisoned training dataset or a model weight downloaded from an untrusted source can create risk without leaving any trace in the code. ML-BOM turns these invisible dependencies into an inventory, so that when a vulnerability or poisoning is disclosed, the question 'were we affected' becomes answerable. It is the inventory leg of model supply-chain assurance, and provenance and attestation tie this inventory to evidence.
AI Model Supply-Chain Assurance.
Model Supply Chain
An evidence-based assessment of the trustworthiness of the model and the release pipeline across the data, pipeline, registry and deployment chain. It is the backbone concept of AI Model Supply-Chain Assurance. It must not be confused with the runtime chain (Generative AI Red Team), and this distinction is the heart of the concept: one examines trust in the model's production process, the other risk in the behavior that arises while the model runs. The first asks 'can I trust this model and the pipeline that produced it', the second 'what can this model do while it runs'. Model supply-chain assurance asks the first question separately at every link of the chain: did the training data come from a trusted source, was the build pipeline hardened, was the promote decision to the registry audited, can the artefact be altered at the moment of deployment. Supply-chain attacks like SolarWinds and XZ Utils show why these questions are vital: even the best-defended system collapses from within if a component it trusts is poisoned. SLSA frames the maturity levels, and provenance and attestation the evidence of each link.
AI Model Supply-Chain Assurance.
MTTR (Mean Time To Remediate)
The average time from a finding being reported to the moment its closure is verified. When measuring the worth of security work, the count of findings is a misleading metric; because risk is reduced not by the vulnerability found but by the one closed. Reporting a hundred findings is an activity indicator, while how long those findings take to close is an outcome indicator. MTTR is this second dimension, the one that measures real effect, and its critical subtlety is in its definition: the duration measured must run not to the moment of 'said to be closed' but to the moment of 'verified as closed'. So MTTR rests on verifiable closure; otherwise the number turns into a misleading optimism adorned with vulnerabilities that are assumed closed but are not. It is tracked as a trend line in the rhythm of the Continuous Penetration Test: if the monthly average is falling, the organization's remediation reflex is quickening; if it is rising, a bottleneck is building. It is one of the core decision metrics of management visibility.
Continuous Penetration Testing.
Non-human Identity (NHI)
Identities with no person behind them: service accounts, application registrations, workload identities and automation keys. In modern cloud environments they outnumber human identities many times over, and this ratio keeps growing as automation increases. Three structural traits make them especially risky: they usually fall outside multi-factor authentication (MFA), their credentials (keys, tokens, certificates) are carried statically in code or configuration, and their lifecycle management is incomplete; a service account forgotten when a project ends can stay alive and privileged for years. From the attacker's side, when these three traits combine, an attractive target arises: they are numerous, weakly protected and unwatched. Moreover, when a non-human identity is seized, its behavior does not produce anomalies the way a human's would, which makes detection harder. Non-human identity management is therefore the fast-growing open flank of cloud security and an inseparable part of effective-permission and transitive-privilege analysis.
Cloud Security Penetration Test.
Observability
Recording every step of an AI-assisted workflow with logging, audit trail, telemetry and rollback criteria; making the work open to human oversight and traceable on an evidence basis. It is not the same as monitoring, and this distinction matters: monitoring asks 'is the system working', observability asks 'what happened, why, and can I undo it'. The first is a status light, the second a black-box recording. In AI-assisted offensive workflows these four components must be preserved together; if one is missing, the workflow runs with a blind spot. Logging carries what was done, the audit trail who did it with what authority, telemetry how the process behaved, and rollback how the result of a wrong step is reversed. Observability is the structure that turns automation from a leap of faith into an accountable process; it is the technical ground of the approval model and human-in-the-loop.
AI for Pentest & Red Team.
Offensive Security
A category of security practice that aims to produce defensible assurance by moving from the attacker's side. It is not the same as 'hacking' or 'cyber attack'; it is a discipline with scope, rules and evidence object defined in advance, running under controlled execution. Where it parts from defense is not a difference of tool or technique but of perspective: defense asks 'what must I protect, which control must I build' and constructs on assumptions; offensive security asks 'how does this break, where would an attacker get in' and brings the answer not with assumption but with evidence. The value of this perspective is this: whether a defensive control actually works is understood only when it is tested by someone trying to break it; an architecture that looks correct on paper may harbor an attack path in the field. Offensive security closes this gap: it surfaces the defense's blind spots through the attacker's eyes and methods, but without the attacker's intent and lack of a frame. The Red in Pulse category identity rests on this ground; all of the firm's services are framed as applications of this discipline.
All offensive-assurance services.
OWASP ASVS
OWASP Application Security Verification Standard, the web application security verification standard. With categories spanning authentication, access control, data protection and business logic, it defines security control requirements in layers and, with three verification levels (L1-L3), scales the security maturity expected of an application. Application Security Penetration Test reports can be presented aligned with ASVS categories, and it is used for control mapping in the audit-ready evidence package. Its real value is a translation function: a penetration test naturally speaks the language of 'this finding, that vulnerability', while an auditor or manager speaks the language of 'which requirement is met, which is open'. ASVS ties these two languages together; it turns a list of 'what we found' into a table of 'which verification item passed, which failed'. A technical finding thus gains a structured form the organization's compliance and assurance counterparts recognize, and the report addresses not only the technical team but decision-makers too. Its mobile counterpart is OWASP MASVS/MASTG.
Application Security Penetration Test.
OWASP LLM Top 10
A list, compiled by OWASP, of the ten most critical security risks in generative-AI and large language model (LLM) applications. It covers headings such as direct and indirect prompt injection, sensitive-information disclosure, supply-chain weakness, excessive agent autonomy and insecure output handling. It is the framework reference of Generative AI Red Team reporting. Its function is to set a common priority language in a threat area that is still very new and fast-changing; this is especially valuable in AI security because the field met a huge adoption pace before gaining technical maturity. When an organization takes an AI application to production, it often has no systematic answer to 'what should I watch for'; the OWASP LLM Top 10 fills this gap and takes a finding out of being 'an interesting problem' and settles it into a recognized, documented risk category with countermeasures already discussed. What the OWASP Top 10 is for traditional web, this list is for LLM applications; together with MITRE ATLAS it is used to frame abuse-path steps.
Generative AI Red Team.
OWASP MASVS / MASTG
The Mobile Application Security Verification Standard (MASVS) and the Mobile Application Security Testing Guide (MASTG). One defines the security control requirements a mobile application must meet, the other gives the methodological framework for how those requirements are tested; the role ASVS plays for web is taken up in the mobile world by this pair. It is the ground reference in the mobile scope of the Application Security Penetration Test. The need for a separate standard arises because mobile has its own attack surface, different from web: the application runs on a device physically in the user's hand, that is, one the attacker can also control. This brings questions web methodology cannot cover; sensitive data in local storage, safe use of platform APIs, over-reliance on the client side, certificate pinning and resistance to reverse engineering are mobile-specific validation areas. This framework is needed to test a mobile application not only against threats from network traffic but also against those from the device itself.
Application Security Penetration Test.
Penetration Test
An offensive test run under controlled execution to produce validated technical evidence. It has four scopes in the Red in Pulse portfolio: Application Security (PT-1), Network Security (PT-2), Cloud Security (PT-3) and Continuous Penetration Testing (PT-5); each scope carries a distinct evidence object, and the PT- code is not used as a heading without explanation. What the concept is most often confused with is a vulnerability scan, and the difference between them lies not in intent but in method. A scanner automatically searches for known vulnerability signatures and produces a list of possibilities saying 'this might be here'; it is fast, broad, but context-free and full of false positives. A penetration test goes beyond this list: it tests with a safe proof of concept (PoC) whether each possible vulnerability is genuinely exploitable, links vulnerabilities into a real attack path, and shows the business impact. A scan asks 'is the door locked', a penetration test tries to open the door and, if it opens, shows what would be found inside. NIST SP 800-115, PTES and the OWASP methodologies are the frameworks of this discipline; evidence-based validation is its common principle.
All offensive-assurance services.
PoC (Safe Proof of Concept)
A reproducible proof of concept that shows a finding is genuinely exploitable, without destructive side effects, preserving data integrity in production. It is the tangible output of evidence-based validation and the tool that draws the line between 'it can be done' and 'it was done'. A scanner's warning that 'this point may be risky' is a hypothesis; a safe proof of concept turns that hypothesis into a fact shown in the field. But the qualifier 'safe' becomes critical right here and separates the concept from an irresponsible 'exploit show': the aim is not to impress, crash the system or display the force of the attack; the aim is to produce evidence the remediation team can validate in its own environment while not disrupting the service, corrupting data or being irreversible. The side-effect control principle of controlled execution makes this design mandatory. A good proof of concept answers two questions at once: is the vulnerability real, and how is it reproduced; a claim thus becomes an engineering task the product team can act on with confidence.
Evidence object references.
Primary Evidence Object
Each service's real validation product; the decision-closing form of what the ecosystem calls a 'finding'. Security services long described their output by the count of findings; yet a hundred-finding report is a burden if it does not say which work comes first, and a decision if it does. The primary evidence object draws this line: a fix-first backlog in the Application Security Penetration Test, rhythm and measurable closure in the Continuous Penetration Test, a validated attack path in the Modular Red Team Simulation, an abuse path in the Generative AI Red Team. Not a raw list of findings but the evidence that moves the decision. What separates a service from its rivals is not how many findings it reported but what this object is.
All offensive-assurance services.
Privilege Chain
A set of authority relationships in cloud identity and permission models that look harmless alone but, when linked, lead to privilege escalation. As the center of gravity of the modern attack surface shifts from the network to identity, critical risk often accumulates not in a single high-severity vulnerability but in the access paths that ordinary permissions form. AWS IAM role assumption (assume-role), Azure Entra ID subscription-level assignments and GCP service accounts' transitive permissions are typical links of this chain. Such a chain cannot be discovered by reading a configuration list; the question is not whether a permission exists but whether it actually grants passage to the next one, and that is tested only with manual validation and a safe proof of concept (PoC). The finding is therefore not a single misconfiguration but an access path the links produce together; the defense, too, targets not a single permission but the chain-breaking control.
Cloud Security Penetration Test.
Privilege Escalation
Moving the authority held by the current identity to a higher level along a path it was not designed for. It has two forms: horizontal escalation, moving to the rights of another identity at the same level; vertical escalation, climbing to a higher authority level. The concept's central role in attack logic comes from this reality: an attacker rarely starts at the highest authority directly at their target; they usually enter from a low-privilege position, and the real work is accumulating, step by step, the authority to reach the critical target. So a single permission can look harmless on its own yet, as a link in a chain, make reaching the critical target possible; the real question is not 'is this permission dangerous' but 'which escalation does this permission open the door to'. In cloud environments, privilege escalation often happens not through a software vulnerability but through a misconfigured IAM policy, an overly broad role or a transitive-privilege relationship. It is the destination of privilege-chain and effective-permission analysis; the assessment targets not individual permissions but the escalation paths permissions open to one another.
Reading cloud authority chains by access impact.
Prompt Injection
Input that changes a generative-AI model's behavior in a way it was not designed for. Its direct form comes with the user's prompt; its indirect form is triggered when content from external sources the model reads (a web page, file, RAG document, email) is interpreted by the model as instruction. It ranks first in the OWASP LLM Top 10 (LLM01), and this prioritization is no accident; its root cause is not a misconfiguration but the architecture itself. In traditional software, code and data flow through separate channels, and this separation is the foundation of security; in a language model, instruction and data arrive through the same channel, within the same natural-language stream, and the model cannot cleanly separate the two. It cannot know in principle whether an input telling it 'ignore the following text' came from a user or from a document it is reading. So prompt injection is not a vulnerability closable with a single patch but a design boundary that must be managed; the defense rests not on 'sanitizing' the input but on limiting the model's authority and the surface on which it can act.
Prompt, tool and authority chain in agents.
Provenance (Source Origin)
Recording in a verifiable way where, how and from which source every component comes across the model artefact, dataset, code, dependencies, build/CI and deployment chain. It is not a single 'where did the model come from' question but a provenance chain covering data, dependencies, build steps, the registry and the deployment pipeline. Its necessity arises from how modern software is built: a system is no longer written from scratch but assembled from inherited libraries, pre-trained models and external datasets; so the source of a risk is often not in the code an organization wrote but in a component it took over. If origin is unknown, trust in a component is an assumption, not evidence; when a vulnerability is disclosed, even the question 'were we affected' cannot be answered. Attestation signs this provenance to make it portable and verifiable, and SLSA frames the maturity level at which the provenance was produced. Together with the component list (SBOM/ML-BOM) it forms the evidential ground of supply-chain trust.
AI Model Supply-Chain Assurance.
RAG (Retrieval-Augmented Generation)
An architecture that enriches context by pulling relevant fragments from external documents or data sources while the model generates a response. It became widespread to overcome two basic limits of a language model: feeding the model's knowledge, bounded by training data and aging over time, with current, organization-specific data, and grounding answers in a verifiable source. So it is among the central components of the runtime chain in generative-AI applications. But where it adds value is also where it opens risk: RAG brings external content to the model and assumes that content is trusted. When that assumption breaks, a new attack surface arises; an instruction planted in a retrieved document can lead to indirect prompt injection, a knowledge base with a weakly drawn access boundary to sensitive-data disclosure, and an untrusted source to poisoning of the model's answer. The 'trusted source' assumption is both RAG's strength and its weakness; security testing asks which data reaches the model with what authority and boundary, and whether that data could be controlled by an attacker.
Generative AI Red Team.
RBAC (Role-Based Access Control)
An authorization model that governs which operations user and service identities may perform on which resources, through roles and bindings rather than individual permissions. Its prevalence comes from manageability: instead of assigning permissions to hundreds of users one by one, permissions are gathered in roles and users are bound to roles. But the critical subtlety for security is this: a role being assigned is not evidence that a control exists. Because real access, that is, effective permissions, arises from roles stacking, inheritance relationships and conditions, and often differs from the simple sum of individual roles. Two roles believed to be 'read only' can, combined, produce an unexpected write authority, or if a role carries the right to assume another, scope can widen through transitive privilege. So 'a role is assigned' does not mean 'the authority is correct'; the security of an RBAC configuration is tested not by reading role definitions but by verifying each identity's computed real access. The control is shown not by a claim but by a computed outcome.
Cloud Security Penetration Test.
Red Team (Modular Red Team Simulation)
A modular offensive simulation that, along the threat-actor, critical-asset or assumed-breach axis and under controlled execution, proves a validated attack path to the critical target. It has four modules: Threat-Actor Simulation (RT-1), Objective-Based Red Team (RT-2), Assumed Breach Simulation (RT-3) and Human-Layer Initial-Access Package (RT-4A). It is not a scenario version of the Network Security Penetration Test, and this distinction is the heart of the concept: a penetration test finds and lists the vulnerabilities in a system, while a red team proves those vulnerabilities link together into a real business impact. One says 'a lock here is weak', the other says 'through that weak lock, down this corridor, one can reach the vault'. So the red team's question is not 'how many vulnerabilities are there' but 'can an attacker truly reach the critical target, and where does the defense stop them'. MITRE ATT&CK frames the attack-path steps and the detection-gap matrix shows the defense's blindness; the primary evidence object is the attack path, documented with technical traces and a timeline.
The Social Engineering Simulation (PT-4) measures reporting reflex; RT-4A is the human-layer initial-access module. They are not the same.
Refresh Token
A long-lived credential used to obtain a new access token when the current one expires, without forcing the user to re-authenticate. It strikes a balance in modern identity architecture: access tokens are deliberately short-lived, so that even if stolen they lapse quickly; the refresh token removes the constant re-login burden this short life creates. But this convenience carries a risk, and the risk is precisely in its long life. When a refresh token is seized, the attacker can use it to keep producing new access tokens; a single theft thus becomes durable access. Moreover, a user changing their password often does not invalidate existing refresh tokens on its own, which can render the most common defensive reflex ineffective. These traits make the refresh token a far more valuable target for the attacker than the access token. In session and identity security assessments the critical questions are whether the revocation mechanism actually works, whether rotation is applied, and whether a leak can be detected.
Application Security Penetration Test.
Registrable Domain (eTLD+1)
The name one level above a Public Suffix List suffix (the effective top-level domain, eTLD), the name an organization can actually buy and register; in the example 'example.co.uk' is an eTLD+1 while 'co.uk' is only a suffix. This unit looks like a technical detail but is the load-bearing column of the browser security model: many boundaries such as the SameSite cookie policy, Site Isolation and cookie scoping operate at the 'site' scale rather than the 'origin', and the browser's definition of 'site' is precisely the registrable domain. The critical consequence in attack analysis is this: two subdomains sharing the same eTLD+1 are, in the browser's eyes, usually within the same site, and some trust boundaries between them weaken. This is the basic unit of measure for the related-domain attacker threat; the risk created when a subdomain is seized is assessed by which registrable domain it shares. Techniques such as cookie tossing and shadowing also operate over this shared boundary.
Application Security Penetration Test.
Registry
The central system for managing model artefacts, versions and deployment; it is assessed under access control, the promote/rollback flow, audit logging and abuse scenarios. It sits at the center of the model trust chain and must not be confused with a simple file store; because a file store only keeps, while a registry is where the decision is made of which model, which version and whose approval goes to production. This makes it the single most valuable node of the supply chain. From the attacker's logic the difference is decisive: if the registry is compromised, the attacker does not hunt vulnerabilities one by one but alters the deployed model directly, and that change spreads to all consumers through the legitimate deployment pipeline; this is exactly the logic of SolarWinds-type supply-chain attacks. So the assessment focuses not on the model's content but on who accesses the registry with what authority, how the promote decision is audited, and whether provenance and attestation evidence is preserved here.
AI Model Supply-Chain Assurance.
Reporting Rate
The share of employees who notice a suspicious message in a social-engineering simulation and report it to the organization. Unlike the click rate, it measures not who was fooled but the defense's ability to be told, shifting the center of measurement from blaming the individual to assessing the organization's reflex. A high reporting rate means a greater chance that any abnormal contact entering the organization turns into an alarm, because a social-engineering attempt becomes a defensible incident only when it is noticed and passed on. A low rate may point less to a training gap than to a reporting channel that is invisible or burdensome. It is the numeric face of the detect-and-report reflex and carries meaning not alone but together with time-to-report.
Detect-and-report behavior.
Revalidation (Re-test)
A controlled second validation that makes the closure of a fix measurable; the proven form of a 'fixed' claim and the second leg of the fix-verify cycle. The most common and most dangerous assumption in security work is believing a vulnerability has been closed once it is reported; yet a patch can fail in several ways, most of which are invisible to the naked eye. The patch may have been applied in the wrong place, masked only the symptom while leaving the root cause, been effective in one configuration but forgotten in another, or opened a new vulnerability while closing the old one. Revalidation closes this uncertainty: the same vulnerability is tested again with the original exploitation method, and closure is tied to a measurement rather than a word. It is the central step of the monthly rhythm in Continuous Penetration Testing and defines the 'verified as closed' threshold of the mean time to remediate (MTTR); it is also used in the Application Security Penetration Test to measure closure at the end of the project. Its function, in short, is this: sometimes a patch truly closes the flaw, sometimes it leaves its place to another; only a re-test shows which. It is the practical mechanism of verifiable closure.
Continuous Penetration Testing.
RoE (Rules of Engagement)
Rules of Engagement; the document that defines in writing a test's authority scope, permitted and prohibited actions, the test window, approval gates, the escalation channel and the side-effect control frame. It is the documentary ground of controlled execution and works as the technical annex to the contract. Its function is best understood not through a metaphor but through a difference in timing: RoE moves the decisions to be made in a moment of crisis to before the crisis. When an unexpected critical finding is encountered during a test, a production system is put at risk, or an ambiguity arises at the scope boundary, debating 'what should we do' in that moment both wastes time and raises the risk of a wrong decision. RoE holds and settles this debate in advance: who is informed, which action is halted, which data is protected and how, all in writing. So in a moment of surprise the team executes rather than improvises. NIST SP 800-115 and PTES frame the content of this document. A test run without RoE, however technically skilled, is not legally and operationally defensible.
Controlled execution and Rules of Engagement.
Runtime Chain
The real-time behavior chain of a generative-AI application across prompt, tool, data (RAG), Model Context Protocol connection, authority and action surfaces. It is the backbone of the Generative AI Red Team scope; the test looks not at what the model knows but at what this chain can do, because in a modern AI application the risk is no longer that the model completes a sentence wrongly but that it can abuse the tools and authority given to it. It must not be confused with the model trust chain (supply chain): one is behavior that arises while the application runs, the other is the evidence chain of the model's source and build pipeline; one asks 'what happens at runtime', the other 'can I trust this model'. OWASP LLM Top 10 and MITRE ATLAS frame the risks in this chain, and the abuse path is proven on it.
model supply chain - one is runtime (AIS-1), the other is the source-and-evidence chain (AIS-2).
SLSA
Supply-chain Levels for Software Artifacts; a framework defining increasing trust levels for the software supply chain. It defines, in layers of progressively tightening levels, the build pipeline's provenance generation, source awareness and hardened-process requirements. It is the ground reference in AI Model Supply-Chain Assurance reporting. Its value is in turning security discussions' vaguest word, the adjective 'secure', into a measurable maturity ladder. The question 'is this build pipeline secure' cannot be answered on its own, because security is not a binary state but a gradation. SLSA makes this grade concrete: the lowest level asks only that provenance be recorded, while higher levels require the build process to be tamper-resistant, process controls such as two-person approval, and proof of source integrity. So the level at which an artefact was produced directly tells how much it can be trusted, and when two suppliers make the same 'secure' claim, it makes the real difference between them visible. Attestation signs the evidence of these levels, and provenance forms its basic input.
AI Model Supply-Chain Assurance.
Social Engineering Simulation
A program-level assessment of the human layer; the detect-and-report reflex, time-to-report, correct-escalation percentage and process friction are reduced to an evidence package. The question it asks parts radically from the traditional approach in this area. The classic 'phishing drill' asks 'who was fooled', counts those who clicked and often turns into a tool of shaming or punishment; this approach produces a number but builds no capability, and can even weaken the defense by pushing employees to avoid reporting. The social-engineering simulation instead asks 'does the organization raise the alarm, or does it quietly let them in'. This shifts the center of measurement from the individual's failure to the organization's reflex; because in a large enough organization someone being fooled is inevitable, and what saves it is how fast that moment turns into an alarm. So the frame is deliberately reflex-building, not blaming; the aim is not to catch an employee but to turn the human layer into an early-warning system. It is the canonical name of PT-4, and its primary evidence object is the detect-and-report reflex; voice channels such as vishing are treated as a separate entry surface.
Social Engineering Simulation.
Third-party Trust Pressure
The continuous burden of providing evidence created by the security-posture assessments an organization undergoes from its customers, business partners or regulator. It is the trigger of the portable-assurance line (S4-A). The concept names a role change security has gone through in recent years: security is no longer only a matter of an organization protecting itself but of proving to others that it is trustworthy. As supply-chain attacks rose, organizations realized that every supplier they work with is a risk gateway; so before buying a service they now question that supplier's security posture. This pressure is continuous, because every new customer, every new partnership and every contract renewal demands the evidence be presented anew. It is not the same as audit and regulation pressure (S4-B), and the difference is in the counterpart: third-party trust pressure arises from the commercial question 'can we work with you, can we trust you'; audit pressure from 'is the legal requirement met'. The strategic consequence of this pressure is this: security stops being an activity of the technical team and becomes a condition of the sales and partnership table; the matter is no longer only being secure but being able to prove it at any moment.
Client security review (vendor FAQ).
Time To Report
The time between a simulation message reaching an employee and the first report arriving. In social-engineering measurement the click rate was long treated as the only metric; yet what saves an organization in a real incident is not that no one clicked but how early the defense is told even if someone did. This duration measures exactly that: it shows how many minutes into a real incident the defense could begin to act, and the smaller the number, the closer the human layer comes to an early-warning system. It is independent of whether anyone clicked; a fast report can close an incident before it grows. It is read together with the reporting rate and the correct-escalation percentage, and is one of the decision metrics of the Social Engineering Simulation.
Detect-and-report behavior.
Transitive Privilege
The rights an identity reaches indirectly through its ability to assume another identity. Examined one by one, no identity looks over-privileged, yet following the assumption chain can reveal far broader effective permissions; if identity A can assume B and B can assume C, A in fact holds all of C's rights. The danger is here: an audit that looks at each identity separately returns a clean result, because no single authority rule is violated; yet the attacker uses identities as a chain, not one at a time. AWS IAM role assumption (assume-role), Azure Entra ID managed identities and GCP service-account impersonation are typical links of this chain. In cloud IAM assessments, transitive privilege is the most overlooked path to privilege escalation and the basic building block of the privilege chain. The assessment therefore targets not individual permissions but the assumption graph that permissions open to one another.
Reading cloud authority chains by access impact.
Verifiable Closure
The proven form of a 'fixed' claim, demonstrated by re-measurement, revalidation (re-test) or control-effectiveness tracking. The quietest failure in security work hides here: a vulnerability is assumed closed, yet the patch was applied in the wrong place, opened a new weakness, or merely masked the symptom. Verifiable closure ties this assumption to a measurement; within the fix-verify cycle it rests closure on evidence, not a word. It is the backbone of rhythm-based closure visibility in the Continuous Penetration Test, and the mean time to remediate (MTTR) carries meaning only when set on this ground, because the duration measured must run to the moment of 'verified as closed', not 'said to be closed'. Whether a finding is truly closed is told not by the one who claims it but by independent measurement; the gap between the two is the threshold that determines the report's credibility.
Continuous Penetration Testing.
Vishing (Voice Social Engineering)
A form of social engineering carried out over the phone or a voice channel, usually targeting help desk and identity verification processes (voice + phishing). In the Social Engineering Simulation it is treated as a separate entry surface, because it exercises a reflex different from the one email-based simulations measure. In an email-based phishing attempt the victim has time to think, to examine a link, to ask a colleague; in voice contact this room disappears. The voice on the other end of the line establishes an immediate pressure, creates a sense of urgency, and makes it socially hard to say 'let me think for a minute'. The persuasive power of the human voice and the pressure to improvise often disable the cautious reflexes that engage in written communication. So an organization succeeding in its email simulations does not mean it is resilient against a voice attack; the two surfaces must be tested separately. Password-reset and account-recovery processes in particular are the most fragile points: a help-desk employee, unable to verify the caller's identity face to face, can come under pressure to grant a critical authority based only on a voice and the story being told.
Social Engineering Simulation.
Go deeper
Service Portfolio
For each of the nine services, it presents the decision question, the evidence object, and the scope architecture together.
Go to the portfolio Decision treeService Selection Decision Tree
It helps you work out, step by step, which service is the right first move in which situation.
Open the decision tree ComplianceCompliance Mapping Matrix
It shows, in one place, how service scopes map to KVKK, ISO 27001, NIST CSF, and OWASP ASVS.
Open the matrix Vendor FAQCustomer Security Review FAQ
A vendor question repository providing an Evidence-Based response framework for the SIG, CAIQ, and VSAQ categories.
Go to the FAQ// TERMINOLOGY
You have explored the glossary; let us unpack the decision question together.
In a discovery call, let us ground on evidence which concept corresponds to which decision priority in your organization.