# The language of secure AI A glossary of 116 proxy, credential security, AI governance, privacy, and risk terms. Educational information only, not legal advice. These general definitions may omit facts that matter to a specific situation and do not establish or guarantee compliance. ## AES-256-GCM Category: Credentials & security AES-256-GCM is an authenticated-encryption mode that uses AES with a 256-bit key to protect data confidentiality and integrity. It produces ciphertext and an authentication tag; correct implementations must use a unique nonce for each encryption under the same key. **Why it matters in practice:** The algorithm provides a cryptographic primitive, not a complete key-storage or access-control design. Nonce management, key rotation, validation of the authentication tag, and safe error handling are essential. Using a strong cipher cannot compensate for exposed keys, unsafe application logic, or missing authorization. **Example:** A service encrypts a stored test secret with a managed key and verifies the authentication tag before using the decrypted value. Related: [Envelope encryption](/glossary/envelope-encryption), [Key management service (KMS)](/glossary/key-management-service), [Post-quantum cryptography](/glossary/post-quantum-cryptography), [Credential vault](/glossary/credential-vault) Read online: [/glossary/aes-256-gcm](/glossary/aes-256-gcm) ## Agent Governance Category: AI governance Agent governance is the set of policies, roles, technical boundaries, and review practices used to guide autonomous software agents. It covers how agents are approved, what data and tools they may use, how their actions are observed, and how people can intervene when outcomes need review. **Why it matters in practice:** An agent can call tools and change external state, so governance must describe more than model quality. Teams connect identity, permissions, logging, evaluations, escalation paths, and ownership to the agent lifecycle. The controls are specific to each deployment; a governance program is not itself proof that an agent is safe or compliant. **Example:** A team inventories an assistant, limits its ticketing tool to a test workspace, records tool actions, and routes unusual account changes to a reviewer. Related: [AI Governance](/glossary/ai-governance), [AI Accountability](/glossary/ai-accountability), [Guardian Agents](/glossary/guardian-agents), [AI Safety](/glossary/ai-safety) Read online: [/glossary/agent-governance](/glossary/agent-governance) ## AI Accountability Category: AI governance AI accountability means assigning responsibility for decisions and impacts involving an artificial intelligence system. It identifies who owns a system, who can explain its use, who reviews harms or errors, and who has authority to change or stop the system when evidence warrants action. **Why it matters in practice:** Accountability turns broad principles into named duties across developers, operators, business owners, and oversight teams. Clear records help an organization answer questions about a model’s purpose, data, approvals, and observed behavior. The term describes an organizational practice, not a guarantee that a system will produce fair or correct results. **Example:** A product team names an owner for a recommendation model and documents who reviews a complaint about an unexpected recommendation. Related: [AI Governance](/glossary/ai-governance), [Responsible AI](/glossary/responsible-ai), [Trustworthy AI](/glossary/trustworthy-ai), [AI Explainability](/glossary/ai-explainability) Read online: [/glossary/ai-accountability](/glossary/ai-accountability) ## AI Act High-Risk Systems Category: Regulation & risk An AI Act high-risk system is an artificial intelligence system that falls within a high-risk category under the European Union Artificial Intelligence Act. The classification is based on the system’s intended purpose and the applicable legal criteria, rather than on a general label about how advanced a model is. **Why it matters in practice:** The label matters because the Act associates different governance duties with different system categories. Classification therefore starts with a concrete description of intended use and the relevant provisions, then receives appropriate legal and technical review. This glossary does not determine whether any particular system is covered or satisfies a requirement. **Example:** A team evaluates a proposed decision-support use against the Act’s classification rules instead of assuming the same model has one risk category in every context. Related: [EU AI Act](/glossary/eu-ai-act), [AI Conformity Assessment](/glossary/ai-conformity-assessment), [AI Risk Management](/glossary/ai-risk-management), [AI Impact Assessment (AIIA)](/glossary/ai-impact-assessment-aiia) Read online: [/glossary/ai-act-high-risk-systems](/glossary/ai-act-high-risk-systems) ## AI Compliance Category: Regulation & risk AI compliance is the work of identifying and meeting legal, contractual, and internal requirements that apply to an artificial intelligence system. It combines scoping, evidence, controls, and review; it is not a single certification or a synonym for ethical or technically reliable model behavior. **Why it matters in practice:** Requirements can differ by system purpose, organization, data, and operating environment, so teams need to map the relevant obligations before selecting controls. Keeping decisions and evidence together makes review more tractable as systems change. A checklist can support this work, but cannot establish compliance without context and qualified assessment. **Example:** A project team maps its system’s intended use to the requirements selected by counsel, records control owners, and keeps evidence with the release review. Related: [AI Governance](/glossary/ai-governance), [EU AI Act](/glossary/eu-ai-act), [AI Risk Management](/glossary/ai-risk-management), [GRC](/glossary/governance-risk-and-compliance-grc) Read online: [/glossary/ai-compliance](/glossary/ai-compliance) ## AI Conformity Assessment Category: Regulation & risk An AI conformity assessment is a structured evaluation of whether a defined artificial intelligence system meets requirements that apply to it. The process examines evidence against specified criteria; its form and outcome depend on the governing framework and the system’s classification. **Why it matters in practice:** Assessment makes a compliance claim reviewable by connecting system documentation, controls, test evidence, and responsible decisions. It should be tied to a particular system and scope, rather than generalized to every model from one supplier. An assessment process does not replace ongoing monitoring or establish that future changes remain within scope. **Example:** Before a release, a team assembles the applicable technical records and test results, then has the designated reviewer compare them with the assessment criteria. Related: [AI Act High-Risk Systems](/glossary/ai-act-high-risk-systems), [EU AI Act](/glossary/eu-ai-act), [AI Compliance](/glossary/ai-compliance), [AI Risk Management](/glossary/ai-risk-management) Read online: [/glossary/ai-conformity-assessment](/glossary/ai-conformity-assessment) ## AI DPIA Category: Privacy & data An AI DPIA is a data protection impact assessment that examines how a proposed artificial intelligence use may affect people’s privacy. It describes the personal-data processing, identifies relevant risks, and records safeguards and decisions in the format required by the organization’s applicable process. **Why it matters in practice:** AI projects can combine new data sources, inference, and automated decisions, making it important to consider privacy during design rather than after deployment. A DPIA is scoped to the actual processing and should be revisited when that processing materially changes. The term does not mean every AI project legally requires a DPIA. **Example:** A team documents which personal data enters a support classifier, who can see its output, and what review is available when the result affects a person. Related: [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment), [Data Privacy](/glossary/data-privacy), [Data Mapping](/glossary/data-mapping), [Privacy-Enhancing Technologies (PETs)](/glossary/privacy-enhancing-technologies-pets) Read online: [/glossary/ai-dpia](/glossary/ai-dpia) ## AI Explainability Category: AI governance AI explainability is the ability to provide useful reasons or evidence about how an artificial intelligence system produced an output. What counts as useful depends on the audience and decision; an explanation may describe inputs, model behavior, or a local rationale without revealing the model’s complete internal computation. **Why it matters in practice:** Explanations can support debugging, oversight, communication, and contesting consequential outcomes, but a fluent explanation is not automatically faithful to a model’s operation. Teams should distinguish measured evidence from a generated narrative and test whether the explanation serves its intended audience. Explainability alone does not establish accuracy, fairness, or legal sufficiency. **Example:** An analyst compares a feature-attribution report with the model’s recorded inputs before explaining why a particular classification was produced. Related: [AI Accountability](/glossary/ai-accountability), [AI Fairness](/glossary/ai-fairness), [Bias Detection](/glossary/bias-detection), [Trustworthy AI](/glossary/trustworthy-ai) Read online: [/glossary/ai-explainability](/glossary/ai-explainability) ## AI Fairness Category: AI governance AI fairness is the evaluation of whether an artificial intelligence system treats people or groups acceptably under a chosen fairness criterion. The relevant criterion depends on the decision, data, and affected population; different metrics can conflict, so the term does not imply one universal test or outcome. **Why it matters in practice:** Fairness work begins by understanding the decision and who may be affected, then selecting defensible measures and examining data and system behavior. Results need interpretation alongside domain knowledge and qualitative review. A fairness label or a single benchmark score cannot prove that a model is unbiased across all uses or groups. **Example:** A hiring team compares error patterns across relevant groups, reviews the data and task design, and records why the selected measure fits the decision. Related: [Bias Detection](/glossary/bias-detection), [Algorithmic Bias](/glossary/algorithmic-bias), [AI Explainability](/glossary/ai-explainability), [Responsible AI](/glossary/responsible-ai) Read online: [/glossary/ai-fairness](/glossary/ai-fairness) ## AI Governance Category: AI governance AI governance is the organizational framework for making and overseeing decisions about artificial intelligence systems. It defines ownership, approval, risk review, documentation, monitoring, and change control so that responsibilities remain clear from initial design through operation and retirement. **Why it matters in practice:** A governance framework connects business purpose with technical controls and human oversight. Its policies should be translated into evidence that teams can use during reviews, incidents, and changes. The framework must fit the organization and system; adopting governance language does not make a model trustworthy or guarantee that every obligation is met. **Example:** An organization records each model’s owner, intended use, review status, monitoring plan, and escalation contact in a maintained inventory. Related: [Agent Governance](/glossary/agent-governance), [AI Risk Management](/glossary/ai-risk-management), [Responsible AI](/glossary/responsible-ai), [AI Lifecycle Management](/glossary/ai-lifecycle-management) Read online: [/glossary/ai-governance](/glossary/ai-governance) ## AI Impact Assessment (AIIA) Category: AI governance An AI impact assessment examines the expected effects of an artificial intelligence system on people, organizations, and the surrounding environment. It records the intended use, affected stakeholders, likely benefits and harms, uncertainty, and options for reducing or monitoring identified impacts. **Why it matters in practice:** Impact assessment helps teams bring technical, operational, and human consequences into a decision before a system is widely used. Its scope and method should match the system and decision being reviewed. It is distinct from a privacy-only assessment and should not be treated as a substitute for legal analysis. **Example:** A service team maps who may be affected by automated ticket prioritization, then documents possible delays and a way for staff to correct a bad ranking. Related: [AI Risk Management](/glossary/ai-risk-management), [AI Governance](/glossary/ai-governance), [AI Accountability](/glossary/ai-accountability), [AI DPIA](/glossary/ai-dpia) Read online: [/glossary/ai-impact-assessment-aiia](/glossary/ai-impact-assessment-aiia) ## AI Lifecycle Management Category: AI governance AI lifecycle management is the coordinated oversight of an artificial intelligence system as it is proposed, built or selected, validated, deployed, monitored, changed, and retired. It keeps the system’s purpose, ownership, evidence, and controls connected as technical and organizational conditions evolve. **Why it matters in practice:** A model’s risk profile can change when its data, users, integrations, or operating context changes. Lifecycle processes make those changes visible and create points for review rather than treating launch as the end of governance. The exact stages differ across organizations and system types. **Example:** A team opens a review when it changes a model’s intended use, repeats relevant tests, updates the inventory, and records the next monitoring owner. Related: [AI Governance](/glossary/ai-governance), [AI Model Inventory](/glossary/ai-model-inventory), [AI Model Drift](/glossary/ai-model-drift), [AI Risk Management](/glossary/ai-risk-management) Read online: [/glossary/ai-lifecycle-management](/glossary/ai-lifecycle-management) ## AI Model Drift Category: AI governance AI model drift is a change in the relationship between a model’s inputs and the outcomes it is expected to predict or classify. It can appear as changed input patterns, changed target behavior, or declining performance, and must be distinguished from random variation in observed results. **Why it matters in practice:** Monitoring can reveal that a model’s original validation no longer reflects the environment where it operates. Teams choose signals tied to the intended task, investigate meaningful changes, and decide whether recalibration, retraining, or withdrawal is appropriate. A drift alert is evidence to review, not proof that the model is failing. **Example:** A support team notices that incoming ticket topics have shifted, checks label quality and error rates, and compares the live sample with its validation data. Related: [AI Model Inventory](/glossary/ai-model-inventory), [AI Lifecycle Management](/glossary/ai-lifecycle-management), [Model Risk Management (MRM)](/glossary/model-risk-management), [Bias Detection](/glossary/bias-detection) Read online: [/glossary/ai-model-drift](/glossary/ai-model-drift) ## AI Model Inventory Category: AI governance An AI model inventory is a maintained record of artificial intelligence models an organization develops, acquires, or uses. Useful records identify a model, its owner, intended purpose, dependencies, lifecycle state, and the evidence or reviews associated with that use. **Why it matters in practice:** A reliable inventory helps teams discover overlapping systems, locate accountable owners, and prioritize review. It also provides a starting point for change tracking and incident response. Inventory fields should reflect actual governance needs; a list of model names alone does not describe how the systems affect operations or people. **Example:** A security team links a text-classification model to its owning service, data flow, deployment environment, and review contact. Related: [AI Lifecycle Management](/glossary/ai-lifecycle-management), [AI Governance](/glossary/ai-governance), [Model Risk Management (MRM)](/glossary/model-risk-management), [Foundation Models](/glossary/foundation-models) Read online: [/glossary/ai-model-inventory](/glossary/ai-model-inventory) ## AI Risk Management Category: Regulation & risk AI risk management is the repeated process of identifying, analyzing, treating, and monitoring risks associated with an artificial intelligence system. It considers the system’s intended use and context, and assigns decisions to people with authority to accept, reduce, transfer, or avoid a risk. **Why it matters in practice:** Risks may arise from data, model behavior, security, human reliance, or the way a system is integrated into a workflow. A documented process helps teams compare concerns, choose controls, and revisit decisions when evidence changes. Risk management is context-specific and does not promise that all uncertainty or harm can be eliminated. **Example:** A team records a model’s failure scenarios, assigns owners to mitigations, and schedules review when the surrounding workflow changes. Related: [NIST AI Risk Management Framework (AI RMF)](/glossary/nist-ai-risk-management), [AI Governance](/glossary/ai-governance), [AI Safety](/glossary/ai-safety), [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management) Read online: [/glossary/ai-risk-management](/glossary/ai-risk-management) ## AI Safety Category: AI governance AI safety is the technical and organizational work of reducing the likelihood and impact of harmful or unreliable behavior from artificial intelligence systems. It can include testing, access boundaries, monitoring, human review, and response planning, selected for a system’s capabilities and use context. **Why it matters in practice:** Safety is broader than an individual model test because system behavior also depends on data, tools, users, and deployment choices. Teams should state which hazards they address and how evidence supports the control. Calling a system safe without a defined scope, assumptions, and ongoing review can obscure unresolved risk. **Example:** Before connecting an assistant to a live account tool, its team tests misuse cases and restricts the tool to read-only actions until review is complete. Related: [AI Risk Management](/glossary/ai-risk-management), [Guardian Agents](/glossary/guardian-agents), [Trustworthy AI](/glossary/trustworthy-ai), [Agent Governance](/glossary/agent-governance) Read online: [/glossary/ai-safety](/glossary/ai-safety) ## Algorithmic Bias Category: AI governance Algorithmic bias is a systematic pattern in an automated system that can produce uneven or unjust outcomes. It may stem from data collection, labeling, model design, thresholds, or deployment context; identifying a disparity does not by itself explain its cause or decide whether it is legally discriminatory. **Why it matters in practice:** Bias analysis examines how design choices and real-world conditions affect different people or groups. It combines quantitative tests with domain understanding and review of the decision process. Teams should document the population, outcome, and limitations studied, because a result on one dataset cannot establish fairness for every use. **Example:** A team checks whether a screening model produces different error patterns across groups, then investigates the labels and workflow behind the disparity. Related: [Bias Detection](/glossary/bias-detection), [AI Fairness](/glossary/ai-fairness), [AI Explainability](/glossary/ai-explainability), [Data Ethics](/glossary/data-ethics) Read online: [/glossary/algorithmic-bias](/glossary/algorithmic-bias) ## API key Category: Credentials & security An API key is a secret or identifier used by an application to present a credential to an API. Depending on the service, it may identify a client, authorize selected operations, or both; possession can be sufficient for use, so handling and scope matter. **Why it matters in practice:** Keys are commonly sent in a header or another documented request field and should be protected from source control, logs, and unintended clients. A key for an upstream API is not the same credential used to authenticate to a forward proxy. Storage, rotation, and permissions should match its intended purpose. **Example:** A worker sends a placeholder-backed key to api.example.com in the header required by that service, without placing the value in its repository. Related: [Proxy authentication](/glossary/proxy-authentication), [Authorization header](/glossary/authorization-header), [Bearer token](/glossary/bearer-token), [Credential injection](/glossary/credential-injection) Read online: [/glossary/api-key](/glossary/api-key) ## Australian Privacy Act Category: Privacy & data The Australian Privacy Act is a federal Australian law that establishes a framework for handling personal information by covered organizations and agencies. It includes the Australian Privacy Principles and other provisions; its application depends on the facts and current law. **Why it matters in practice:** The Act is a central reference for organizations assessing privacy practices connected with Australia. Teams typically use it alongside internal data maps and qualified advice to understand how collection, use, disclosure, and security are addressed. This glossary offers a general identity only and does not summarize every exception or obligation. **Example:** A privacy team maps a customer-data flow and asks counsel to assess how the flow relates to the Act before changing the product notice. Related: [Australian Privacy Principles (APPs)](/glossary/australian-privacy-principles-apps), [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment) Read online: [/glossary/australian-privacy-act](/glossary/australian-privacy-act) ## Australian Privacy Principles (APPs) Category: Privacy & data The Australian Privacy Principles (APPs) are the principles in the Australian Privacy Act that set out a framework for handling personal information. They address areas such as collection, use, disclosure, data quality, security, access, and transparency for entities to which they apply. **Why it matters in practice:** The APPs offer a useful structure for reviewing privacy practices, but applying a principle requires understanding the data flow and legal context. An organization should not assume the same analysis covers every entity or activity. The principles are related to, but not interchangeable with, the full Australian Privacy Act. **Example:** A team reviews how an intake form explains collection and how stored information is protected, then records questions for a qualified legal review. Related: [Australian Privacy Act](/glossary/australian-privacy-act), [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/australian-privacy-principles-apps](/glossary/australian-privacy-principles-apps) ## Australian Prudential Regulation Authority (APRA) Category: Regulation & risk The Australian Prudential Regulation Authority (APRA) is Australia’s independent prudential regulator for parts of the financial system, including banking, insurance, and superannuation. It supervises regulated institutions with a focus on their financial safety and stability. **Why it matters in practice:** APRA is an institution, not a privacy statute or a general label for every Australian regulator. Organizations use its materials to understand prudential expectations that apply to the entities and activities in scope. This entry describes the regulator’s basic identity and does not determine whether an organization is regulated. **Example:** A financial organization checks whether its entity and activity fall within APRA’s remit before assigning an internal owner to review relevant supervisory material. Related: [Tech Risk Management](/glossary/tech-risk-management), [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management), [DORA (Digital Operational Resilience Act)](/glossary/dora), [Third-Party Risk Management (TPRM)](/glossary/third-party-risk-management-tprm) Read online: [/glossary/apac-apra](/glossary/apac-apra) ## Authorization header Category: Credentials & security The HTTP Authorization header carries credentials that a client presents to the server responsible for the requested resource. The scheme determines how the value is interpreted; the header is separate from Proxy-Authorization, which is intended for a proxy hop. **Why it matters in practice:** Applications often use Authorization for an upstream API token, but header handling depends on the protocol and service. Proxies that modify requests must preserve the intended recipient and prevent credentials from leaking across hosts. Encrypting transport protects the header in transit only between the endpoints of that TLS connection. **Example:** A client sends a bearer credential in Authorization to api.example.com after the proxy connection has been established. Related: [Proxy-Authorization header](/glossary/proxy-authorization-header), [Bearer token](/glossary/bearer-token), [API key](/glossary/api-key), [Credential injection](/glossary/credential-injection) Read online: [/glossary/authorization-header](/glossary/authorization-header) ## Auto-Auth mode Category: Credentials & security Auto-Auth mode is a proxy operating mode that applies configured credentials to requests for approved services. For HTTPS CONNECT requests that require request rewriting, it inspects TLS traffic and needs the client to trust the proxy certificate authority; it is not opaque TLS pass-through. **Why it matters in practice:** Auto-Auth uses placeholders and service bindings to choose which secret is inserted and where. For inspected HTTPS, configure the client to trust the proxy's public CA certificate in the intended application or container. This trust is distinct from presenting a client certificate for mutual TLS. **Example:** A worker trusts the configured proxy CA, connects through Auto-Auth, and sends a placeholder that is replaced for api.example.com. Related: [Credential injection](/glossary/credential-injection), [Firewall mode](/glossary/firewall-mode), [TLS inspection](/glossary/tls-inspection), [Certificate authority (CA)](/glossary/certificate-authority) Read online: [/glossary/auto-auth-mode](/glossary/auto-auth-mode) ## Bearer token Category: Credentials & security A bearer token is a credential whose holder can exercise the permissions associated with it, without proving possession of a separate private key. The resource server evaluates the token and its context; the token’s name alone does not reveal its exact scope or lifetime. **Why it matters in practice:** Bearer tokens should be protected from disclosure because anyone who obtains a usable token may be able to present it. TLS, narrow permissions, expiry, and careful storage reduce exposure but do not eliminate misuse risk. A token may authenticate to an API or proxy depending on the service and request header. **Example:** A client presents a short-lived placeholder-backed bearer token to api.example.com and avoids printing the value in diagnostic output. Related: [Authorization header](/glossary/authorization-header), [Proxy authentication](/glossary/proxy-authentication), [API key](/glossary/api-key), [Capability token](/glossary/capability-token) Read online: [/glossary/bearer-token](/glossary/bearer-token) ## Bias Detection Category: AI governance Bias detection is the process of looking for systematic differences or unwanted patterns in a dataset, model, or automated decision process. It uses methods chosen for the task and available evidence, and findings require interpretation before anyone concludes that a system is fair or unfair. **Why it matters in practice:** Useful detection begins with a clear outcome, population, and comparison, then examines the data and model at appropriate stages. Reviewers should note sample limitations and distinguish a signal from a causal explanation. Detection can inform remediation, but it does not independently select the right fairness standard or control. **Example:** An analyst compares false-positive rates across relevant groups, checks sample sizes, and traces a difference back through labels and decision thresholds. Related: [AI Fairness](/glossary/ai-fairness), [Algorithmic Bias](/glossary/algorithmic-bias), [AI Explainability](/glossary/ai-explainability), [AI Model Drift](/glossary/ai-model-drift) Read online: [/glossary/bias-detection](/glossary/bias-detection) ## Capability token Category: Credentials & security A capability token is a credential that conveys authority to perform a defined action on a resource. Systems can limit that authority by scope, audience, use count, or expiry; the token’s actual capabilities are determined by how the receiving service validates it. **Why it matters in practice:** Because possession may grant access, a capability token should be treated as a secret and protected from logs, referrers, and unintended recipients. Narrow scope and revocation reduce some exposure. A token is not safe merely because it is called a capability, and it does not replace the service’s authorization checks. **Example:** A recipient presents a scoped token to access one shared test proxy, while unrelated account actions remain unavailable. Related: [Secure share](/glossary/secure-share), [Bearer token](/glossary/bearer-token), [Proxy authentication](/glossary/proxy-authentication), [Least privilege](/glossary/least-privilege) Read online: [/glossary/capability-token](/glossary/capability-token) ## CCPA (California Consumer Privacy Act) Category: Privacy & data The California Consumer Privacy Act (CCPA) is a California privacy law concerning certain businesses’ handling of personal information and consumer privacy rights. The law has been amended, and its application depends on definitions, thresholds, exceptions, and the facts of a particular activity. **Why it matters in practice:** The CCPA is often considered when organizations map data practices involving California consumers. A useful review distinguishes the law’s text, implementing rules, and related California privacy requirements rather than treating the acronym as a complete compliance checklist. This entry is educational and does not determine coverage or legal obligations. **Example:** A product team inventories categories of information collected through an account flow and asks counsel to evaluate the relevant California requirements. Related: [CPRA (California Privacy Rights Act)](/glossary/cpra), [Customer Data Rights](/glossary/customer-data-rights), [DSAR (Data Subject Access Request)](/glossary/data-subject-access-request), [Data Privacy](/glossary/data-privacy) Read online: [/glossary/california-consumer-privacy-act](/glossary/california-consumer-privacy-act) ## Certificate authority (CA) Category: Credentials & security A certificate authority (CA) is an entity or key hierarchy that issues digital certificates binding public keys to identities under defined rules. Clients use configured trust anchors to decide whether a certificate chain is acceptable; trust depends on the certificate, validation, and client configuration. **Why it matters in practice:** Clients trust the proxy's public CA certificate to validate replacement server certificates for inspected HTTPS. This is not a client-authentication certificate for mutual TLS. Keep the CA's private signing key on the proxy; install only the public certificate in intended client environments. **Example:** A test client adds the proxy’s public CA certificate to its trust store so it can validate the proxy-issued certificate for api.example.com. Related: [TLS inspection](/glossary/tls-inspection), [CONNECT tunnel](/glossary/connect-tunnel), [Auto-Auth mode](/glossary/auto-auth-mode), [Firewall mode](/glossary/firewall-mode) Read online: [/glossary/certificate-authority](/glossary/certificate-authority) ## Chile's Data Protection Law Category: Privacy & data Chile's data protection law is the national legal framework that governs the processing of personal data in Chile. Its requirements, interpretation, and applicability depend on the applicable provisions and the circumstances of the organization and processing activity. **Why it matters in practice:** Organizations use local privacy analysis to understand how information about people is collected, used, shared, and protected in relevant operations. A title alone does not establish which version or provision applies, so implementation questions should be checked against authoritative legal materials. This entry avoids giving a jurisdiction-specific compliance conclusion. **Example:** A company maps a service’s personal-data flows connected with Chile and asks a qualified reviewer to identify which provisions need closer analysis. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [Data Mapping](/glossary/data-mapping), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment) Read online: [/glossary/data-protection-law-in-chile](/glossary/data-protection-law-in-chile) ## CIDR notation Category: Proxy & networking CIDR notation represents an IP network as an address followed by a prefix length, such as an address with “/24”. The prefix length indicates how many leading bits identify the network and therefore which addresses belong to that range. **Why it matters in practice:** A prefix can describe one address or a larger range, so reviewers should check the scope before using it in an allowlist or route. IPv4 and IPv6 have different address lengths. Mistyped or overly broad prefixes can allow more sources than intended. **Example:** A network engineer checks the prefix length for an IPv4 range before adding that range to a test proxy’s allowlist. Related: [IP allowlist](/glossary/ip-allowlist), [Proxy IP](/glossary/proxy-ip), [Static IP address](/glossary/static-ip-address), [Egress filtering](/glossary/egress-filtering) Read online: [/glossary/cidr-notation](/glossary/cidr-notation) ## Hyperproxy Category: Proxy & networking A Hyperproxy receives a client’s outbound request and can add a configured upstream credential before forwarding it. The client authenticates to the proxy separately from the API credential sent to the destination; HTTPS injection requires the proxy to inspect the request rather than pass through opaque TLS. **Why it matters in practice:** This pattern lets an application use a proxy boundary for routing and credential handling instead of embedding an upstream secret in each client. For HTTPS requests that need rewriting, TLS inspection and a trusted proxy certificate authority are part of the connection model. A proxy does not make the upstream service or all outbound traffic safe by itself. **Example:** A worker sends a request through its proxy and uses a configured placeholder for a key that the proxy injects into a request to api.example.com. Related: [Forward proxy](/glossary/forward-proxy), [Credential injection](/glossary/credential-injection), [Secret placeholder](/glossary/secret-placeholder), [Proxy authentication](/glossary/proxy-authentication) Read online: [/glossary/credential-injecting-forward-proxy](/glossary/credential-injecting-forward-proxy) ## CMP (Consent Management Platform) Category: Privacy & data A consent management platform (CMP) is software that presents choices about specified data uses and records related preference signals. Its functions can include a notice interface, preference storage, and integrations with other systems; the platform itself does not establish that a consent request is valid. **Why it matters in practice:** Organizations may use a CMP to make privacy choices consistent across digital experiences and to communicate those choices to connected technologies. Configuration, language, and downstream behavior matter as much as the interface. Teams should distinguish a recorded preference from the legal basis or permission required for a particular processing activity. **Example:** A site displays separate optional categories, saves a visitor’s selection, and passes the selected state to its tag controls. Related: [Cookie Consent](/glossary/cookie-consent), [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/consent-management-platform](/glossary/consent-management-platform) ## Common Expression Language (CEL) Category: Proxy & networking Common Expression Language (CEL) is a non-Turing-complete expression language for evaluating predicates and values in host applications. The language defines syntax and semantics, while each application decides which variables, functions, and operations are available. **Why it matters in practice:** A CEL expression has meaning only within the data and functions supplied by its host. A policy engine may use expressions to test request attributes, but the language does not itself define a firewall policy or guarantee a safe default. Reviewers should test expressions against representative inputs and host-specific behavior. **Example:** A proxy rule evaluates a CEL expression over the request method and destination attributes exposed by that proxy. Related: [Firewall rule](/glossary/firewall-rule), [Firewall mode](/glossary/firewall-mode), [Least privilege](/glossary/least-privilege), [Egress filtering](/glossary/egress-filtering) Read online: [/glossary/common-expression-language](/glossary/common-expression-language) ## CONNECT tunnel Category: Proxy & networking An HTTP CONNECT request asks a proxy to establish a bidirectional tunnel to a destination authority. After the proxy accepts the tunnel, it normally relays bytes rather than interpreting the application protocol carried inside it. **Why it matters in practice:** Clients commonly use CONNECT to carry TLS traffic through an HTTP proxy. When TLS remains opaque, the proxy cannot rewrite encrypted headers or inspect the HTTP method and path. Request-level policy or credential injection needs a separate inspection or termination design, which changes the connection trust model. **Example:** A client asks its proxy to connect to api.example.com, then sends TLS bytes through the established tunnel. Related: [HTTP proxy](/glossary/http-proxy), [HTTPS proxy](/glossary/https-proxy), [TLS inspection](/glossary/tls-inspection), [Certificate authority (CA)](/glossary/certificate-authority) Read online: [/glossary/connect-tunnel](/glossary/connect-tunnel) ## Control plane Category: Proxy & networking A control plane is the part of a distributed system that manages configuration, coordination, and lifecycle decisions for other components. It may provision services, distribute policy, or report status, while data-processing components handle application traffic. **Why it matters in practice:** Separating management operations from request handling can clarify responsibilities and access boundaries. The distinction is architectural rather than absolute, and a control plane may still contain sensitive data or affect service availability. Teams should protect management interfaces and understand how configuration changes reach running components. **Example:** An operator updates a proxy rule through a management API, and the control plane distributes that configuration to the relevant instance. Related: [Data plane](/glossary/data-plane), [Sidecar](/glossary/sidecar), [Forward proxy](/glossary/forward-proxy), [Firewall rule](/glossary/firewall-rule) Read online: [/glossary/control-plane](/glossary/control-plane) ## Cookie Consent Category: Privacy & data Cookie consent is a person’s choice about the placement or use of cookies and similar technologies, where consent is the applicable basis for that activity. A consent interface communicates choices, while the actual legal and technical requirements depend on the technology, purpose, and jurisdiction. **Why it matters in practice:** Consent controls should correspond to what scripts and storage mechanisms actually do. If a preference is collected but optional technologies continue to run, the interface and system behavior diverge. Teams should test the complete page lifecycle and distinguish necessary storage from optional purposes under the rules relevant to their service. **Example:** A visitor declines optional measurement, and a test confirms that the corresponding non-essential tag does not start on the next page. Related: [CMP (Consent Management Platform)](/glossary/consent-management-platform), [Data Privacy](/glossary/data-privacy), [Data Minimization](/glossary/data-minimization), [Customer Data Rights](/glossary/customer-data-rights) Read online: [/glossary/cookie-consent](/glossary/cookie-consent) ## CPRA (California Privacy Rights Act) Category: Privacy & data The California Privacy Rights Act (CPRA) is a California statute that amended and expanded the state’s consumer privacy framework. It is commonly discussed with the CCPA because the two are connected; the applicable requirements should be read in the current California legal context. **Why it matters in practice:** The CPRA is not a separate name for every California privacy obligation. Organizations assessing a practice need to consider the statutory text, regulations, relevant definitions, and whether the provisions apply to their activity. This summary identifies the law at a high level and is not legal advice or a compliance assessment. **Example:** A privacy reviewer checks whether a proposed data-sharing change affects the organization’s analysis of the California privacy framework. Related: [CCPA (California Consumer Privacy Act)](/glossary/california-consumer-privacy-act), [Customer Data Rights](/glossary/customer-data-rights), [DSAR (Data Subject Access Request)](/glossary/data-subject-access-request), [Data Privacy](/glossary/data-privacy) Read online: [/glossary/cpra](/glossary/cpra) ## Credential injection Category: Credentials & security Credential injection is the controlled insertion of a stored credential into a request as it passes through a component that can inspect and modify that request. For HTTPS traffic, rewriting application headers requires TLS termination or inspection; an opaque CONNECT tunnel cannot be rewritten. **Why it matters in practice:** Injection can keep an upstream secret out of application source while still allowing a client to reach a service. The component needs a defined destination, field, and permission boundary, and should avoid exposing the value in logs or responses. TLS inspection requires the client to trust the proxy’s certificate authority and changes the connection’s trust model. **Example:** A client places a configured placeholder in a request to api.example.com, and an inspecting proxy replaces it with the bound upstream credential. Related: [Secret placeholder](/glossary/secret-placeholder), [Credential vault](/glossary/credential-vault), [Host-scoped credentials](/glossary/host-scoped-credentials), [TLS inspection](/glossary/tls-inspection) Read online: [/glossary/credential-injection](/glossary/credential-injection) ## Credential rotation Category: Credentials & security Credential rotation is the replacement of a credential with a new value and the retirement of the previous one. It can reduce the period during which an exposed or stale credential remains usable, provided every dependent service is updated and the old value is actually revoked. **Why it matters in practice:** Rotation requires coordination across secret storage, applications, integrations, and any fallback path. A process should account for failed updates and verify which credential remains accepted. Rotation frequency alone is not a security guarantee; scope, monitoring, access controls, and incident response still matter. **Example:** An operator stores a replacement API key, updates the service binding, checks the test request, and then revokes the superseded key. Related: [Secret expiry](/glossary/secret-expiry), [Credential vault](/glossary/credential-vault), [Write-only secret](/glossary/write-only-secret), [API key](/glossary/api-key) Read online: [/glossary/credential-rotation](/glossary/credential-rotation) ## Credential vault Category: Credentials & security A credential vault is a managed store for sensitive values such as API keys, passwords, or tokens. It separates secret storage from ordinary application configuration and provides controlled operations for creating, binding, using, or retiring credentials. **Why it matters in practice:** A vault is useful only when access paths, encryption, auditing, and recovery are designed for the application’s needs. Storing a value in a vault does not guarantee that it cannot be exposed by an authorized client or misconfigured integration. Hyperproxy vaults group write-only secrets and bind credentials to approved upstream hosts. **Example:** An operator stores a placeholder key in a vault and binds it to a service that may contact api.example.com. Related: [Service binding](/glossary/service-binding), [Host-scoped credentials](/glossary/host-scoped-credentials), [Write-only secret](/glossary/write-only-secret), [Credential rotation](/glossary/credential-rotation) Read online: [/glossary/credential-vault](/glossary/credential-vault) ## Customer Data Rights Category: Privacy & data Customer data rights are the choices or legal rights people may have over information associated with them. Depending on the framework and context, these can include access, correction, deletion, portability, objection, or withdrawal of a preference. **Why it matters in practice:** A rights request usually requires an organization to identify the person and information involved, route the request, assess exceptions, and record a response. The available rights are not identical across laws or data types. Clear procedures help operational teams handle requests without treating this umbrella term as a universal entitlement. **Example:** A service receives a request to access account information, verifies the requester through its established process, and routes the request to the records owner. Related: [DSAR (Data Subject Access Request)](/glossary/data-subject-access-request), [Data Privacy](/glossary/data-privacy), [General Data Protection Regulation (GDPR)](/glossary/gdpr), [Data Minimization](/glossary/data-minimization) Read online: [/glossary/customer-data-rights](/glossary/customer-data-rights) ## Data Classification Category: Privacy & data Data classification is the practice of assigning information to categories based on properties such as sensitivity, confidentiality, or operational importance. A classification scheme gives people and systems a shared way to apply handling rules, retention choices, and access controls. **Why it matters in practice:** Useful labels are defined clearly enough that teams can apply them consistently to files, records, and data flows. Classification should reflect business context and the consequences of exposure, not just a fixed list of technical formats. Labels only help when downstream controls and owners understand what they require. **Example:** A team labels a dataset containing account identifiers as restricted and limits its export path to approved, audited workflows. Related: [Data Discovery](/glossary/data-discovery), [Data Mapping](/glossary/data-mapping), [Data Minimization](/glossary/data-minimization), [Data Retention Policy](/glossary/data-retention-policy) Read online: [/glossary/data-classification](/glossary/data-classification) ## Data Discovery Category: Privacy & data Data discovery is the process of finding and describing data assets across systems, storage locations, and workflows. It can combine interviews, system inventories, scanning, and metadata review to identify what information exists and how it is used. **Why it matters in practice:** Discovery helps teams establish a baseline for privacy, security, retention, and governance work. Automated scanning can miss context or misclassify content, so results should be validated by people who understand the systems. A discovery project is an ongoing activity when technology and data flows continue to change. **Example:** A privacy analyst combines a storage scan with service-owner interviews to locate customer records and note their purpose and access path. Related: [Data Classification](/glossary/data-classification), [Data Mapping](/glossary/data-mapping), [Data Lineage](/glossary/data-lineage), [Data Privacy](/glossary/data-privacy) Read online: [/glossary/data-discovery](/glossary/data-discovery) ## Data Ethics Category: Privacy & data Data ethics is the consideration of values and responsibilities involved in collecting, analyzing, sharing, and using information. It asks whether practices respect people, avoid unjustified harm, and align with stated purposes, alongside any applicable legal and technical requirements. **Why it matters in practice:** Ethical review can surface concerns that are not fully captured by a privacy notice or security control, such as unexpected reuse or uneven effects. Teams need to explain their values, involve relevant perspectives, and record tradeoffs. An ethical label is not a substitute for legal analysis or evidence that a practice is beneficial. **Example:** Before reusing support conversations for analytics, a team considers user expectations, access boundaries, retention, and the value of the analysis. Related: [Responsible AI](/glossary/responsible-ai), [AI Fairness](/glossary/ai-fairness), [Data Minimization](/glossary/data-minimization), [Customer Data Rights](/glossary/customer-data-rights) Read online: [/glossary/data-ethics](/glossary/data-ethics) ## Data Lineage Category: Privacy & data Data lineage describes where data originated, how it moved, and what transformations or uses occurred along the way. It connects sources, processing steps, and destinations so a reviewer can trace a value or dataset through a system. **Why it matters in practice:** Lineage can help explain how an output was produced, locate downstream copies, and assess the effect of a correction or deletion. The level of detail should fit the system and question. A diagram is useful only when it reflects actual processing and is maintained as integrations evolve. **Example:** An engineer traces a report field from an intake record through a transformation job to the dashboard that displays it. Related: [Data Mapping](/glossary/data-mapping), [Data Discovery](/glossary/data-discovery), [Data Classification](/glossary/data-classification), [Data Retention Policy](/glossary/data-retention-policy) Read online: [/glossary/data-lineage](/glossary/data-lineage) ## Data Mapping Category: Privacy & data Data mapping is the documentation of information categories, sources, purposes, systems, recipients, and movement within a defined process. It can be a table or diagram that makes relationships between data and operations understandable to reviewers. **Why it matters in practice:** Teams use maps to support privacy reviews, security analysis, retention planning, and system changes. A map should state its scope and date of validation, because an incomplete or stale representation can create false confidence. It records how people understand a process; it does not by itself authorize that process. **Example:** A service owner maps account details from a form to an internal queue, a processing service, and the storage location used for support. Related: [Data Lineage](/glossary/data-lineage), [Data Discovery](/glossary/data-discovery), [Data Privacy](/glossary/data-privacy), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment) Read online: [/glossary/data-mapping](/glossary/data-mapping) ## Data Minimization Category: Privacy & data Data minimization is the practice of limiting collection, use, access, and retention to information that is justified for a defined purpose. It encourages teams to ask whether each field is needed and whether a less identifying or less detailed alternative can serve the task. **Why it matters in practice:** Reducing unnecessary information can lower exposure and simplify governance, but the right scope depends on purpose and legal requirements. Teams should revisit fields and copies as processes change instead of assuming initial collection is permanently necessary. Minimization is a design principle, not merely a shorter retention period. **Example:** An intake form removes an optional birth date because the support workflow can resolve the request using an account identifier. Related: [Data Privacy](/glossary/data-privacy), [Data Retention Policy](/glossary/data-retention-policy), [Data Classification](/glossary/data-classification), [AI DPIA](/glossary/ai-dpia) Read online: [/glossary/data-minimization](/glossary/data-minimization) ## Data plane Category: Proxy & networking A data plane is the part of a system that processes application traffic or data operations according to configured behavior. In a proxy architecture, it typically handles client connections and forwards requests while the control plane manages policy and lifecycle. **Why it matters in practice:** Data-plane behavior determines what happens to live requests, so latency, capacity, failure handling, and security boundaries matter. The term does not specify a particular network product or guarantee isolation from management systems. Operators need to know which component sees plaintext, credentials, and connection metadata. **Example:** A proxy’s data plane receives a client connection and applies the currently distributed routing behavior to the request. Related: [Control plane](/glossary/control-plane), [Sidecar](/glossary/sidecar), [Forward proxy](/glossary/forward-proxy), [TLS inspection](/glossary/tls-inspection) Read online: [/glossary/data-plane](/glossary/data-plane) ## Data Privacy Category: Privacy & data Data privacy concerns how information about people is collected, used, shared, stored, and governed. It includes people’s interests and choices, organizational responsibilities, and the controls that shape data processing in a specific context. **Why it matters in practice:** Privacy work spans product design, data operations, security, policy, and legal interpretation. A single tool or notice cannot address every question because appropriate handling depends on what information is involved and why. Teams often use data maps and review processes to make those decisions understandable and repeatable. **Example:** A product team identifies what account information a feature needs, explains the purpose, and limits access to the service roles that support it. Related: [Data Mapping](/glossary/data-mapping), [Data Minimization](/glossary/data-minimization), [General Data Protection Regulation (GDPR)](/glossary/gdpr), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment) Read online: [/glossary/data-privacy](/glossary/data-privacy) ## Data Retention Policy Category: Privacy & data A data retention policy states how an organization decides to keep, archive, or dispose of information. It connects information types and purposes with responsible owners, retention criteria, and the process used to apply those decisions. **Why it matters in practice:** Retention decisions may involve business need, legal duties, security, and operational constraints. A policy is effective only when systems and teams can carry out its rules, including copies and backups where relevant. The appropriate duration is context-specific; a generic schedule cannot determine a lawful or necessary period for every dataset. **Example:** A records owner maps an inactive support export to a documented retention rule and verifies that the storage workflow removes it when the rule applies. Related: [Data Minimization](/glossary/data-minimization), [Data Classification](/glossary/data-classification), [Data Privacy](/glossary/data-privacy), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/data-retention-policy](/glossary/data-retention-policy) ## Dedicated proxy Category: Proxy & networking A dedicated proxy is an endpoint and its supporting resources allocated for a particular customer, workload, or purpose rather than shared among a broader set of unrelated users. The isolation boundary depends on the deployment and does not by itself guarantee a static IP or a specific security property. **Why it matters in practice:** Dedicated capacity can make resource ownership and network policy easier to reason about, but operations still depend on patching, access controls, and infrastructure design. “Dedicated” should be defined precisely: it may refer to a process, virtual machine, address, or service allocation, which are not interchangeable. **Example:** A team assigns one Hyperproxy to a sensitive test workflow and documents whether the address and supporting infrastructure are also exclusive. Related: [Static IP address](/glossary/static-ip-address), [Proxy IP](/glossary/proxy-ip), [Proxy port](/glossary/proxy-port), [Forward proxy](/glossary/forward-proxy) Read online: [/glossary/dedicated-proxy](/glossary/dedicated-proxy) ## Digital Personal Data Protection Act (DPDPA) Category: Privacy & data The Digital Personal Data Protection Act (DPDPA) is India’s national law concerning the processing of digital personal data. Its meaning and application are shaped by the statute and related legal materials, as well as the circumstances of the processing being considered. **Why it matters in practice:** Organizations use the DPDPA as a reference when reviewing digital personal-data practices connected with India. An accurate assessment requires checking current authoritative materials and the organization’s role and activity. This glossary entry provides a basic identification only; it does not describe every right, exception, rule, or implementation detail. **Example:** A team documents the digital personal data used in an account workflow and asks its legal reviewer to assess the relevant Indian requirements. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/digital-personal-data-protection-act](/glossary/digital-personal-data-protection-act) ## DNS filtering Category: Proxy & networking DNS filtering applies rules to domain-name queries and can allow, block, or alter a DNS response based on configured criteria. It acts during name resolution, before an application connects to an address, and does not inspect every later packet or application request. **Why it matters in practice:** A resolver may use filtering to enforce a domain policy or reduce access to known unwanted names. The outcome depends on the lists, rule precedence, client path, and DNS configuration. Filtering is not a substitute for network controls, and a successful DNS answer does not establish that a destination is trustworthy. **Example:** A resolver configured for a test network returns a blocked response for a domain on its selected deny list. Related: [DNS resolver](/glossary/dns-resolver), [Domain generation algorithm (DGA)](/glossary/domain-generation-algorithm), [NXDOMAIN](/glossary/nxdomain), [Egress filtering](/glossary/egress-filtering) Read online: [/glossary/dns-filtering](/glossary/dns-filtering) ## DNS over HTTPS (DoH) Category: Proxy & networking DNS over HTTPS (DoH) carries DNS messages inside HTTPS requests between a client and a DoH resolver. Encryption protects that transport from passive observation on the intervening network, but the resolver still receives the DNS question and can apply its own logging or policy. **Why it matters in practice:** DoH can change which resolver handles a device’s lookups and may bypass network-level DNS controls if it is not managed. It is one encrypted DNS transport, not proof that every DNS lookup or subsequent connection is private. Resolver choice, endpoint configuration, and client policy remain important. **Example:** A browser sends a DNS query for api.example.com to its configured DoH service over an HTTPS connection. Related: [DNS resolver](/glossary/dns-resolver), [Private DNS server](/glossary/private-dns-server), [DNS filtering](/glossary/dns-filtering), [DNS tunneling](/glossary/dns-tunneling) Read online: [/glossary/dns-over-https](/glossary/dns-over-https) ## DNS resolver Category: Proxy & networking A DNS resolver answers queries that map domain names to DNS records. A recursive resolver obtains or retrieves an answer for a client, often using caches and queries to other DNS servers; a stub resolver usually sends requests to a recursive resolver. **Why it matters in practice:** The resolver is a key point in name lookup, but it does not see every detail of an application connection. Standard DNS on port 53 is not inherently encrypted, and a client’s query may still reveal the requested name to the resolver. In Hyperproxy, Pro+ DNS authentication applies to management API calls, not each port 53 lookup. **Example:** A client asks its recursive resolver for the address records associated with api.example.com and then opens a connection using the returned data. Related: [Private DNS server](/glossary/private-dns-server), [DNS filtering](/glossary/dns-filtering), [DNS over HTTPS (DoH)](/glossary/dns-over-https), [NXDOMAIN](/glossary/nxdomain) Read online: [/glossary/dns-resolver](/glossary/dns-resolver) ## DNS tunneling Category: Proxy & networking DNS tunneling encodes non-DNS data inside DNS queries and responses to move information over a channel that appears to be DNS. It can be used for legitimate constrained communications, but attackers may also use it to evade controls or move data. **Why it matters in practice:** Because DNS is commonly permitted, unusual query patterns can be a signal worth investigating. Detection depends on resolver visibility, baseline traffic, and the content or behavior being assessed. Blocking all unusual DNS may disrupt legitimate systems, so alerts should be interpreted with network and application context. **Example:** A monitoring system flags a host that repeatedly sends unusually long subdomain labels to an unfamiliar resolver for investigation. Related: [DNS resolver](/glossary/dns-resolver), [DNS filtering](/glossary/dns-filtering), [Domain generation algorithm (DGA)](/glossary/domain-generation-algorithm), [Egress filtering](/glossary/egress-filtering) Read online: [/glossary/dns-tunneling](/glossary/dns-tunneling) ## Domain generation algorithm (DGA) Category: Proxy & networking A domain generation algorithm (DGA) is a procedure that produces domain-name candidates from inputs such as a seed, time value, or internal state. Some malware uses DGAs to find command infrastructure, while similar generation techniques can also have benign uses. **Why it matters in practice:** A large sequence of unusual or unsuccessful DNS lookups may help analysts detect automated behavior, but a DGA-like pattern is not conclusive proof of compromise. Monitoring combines query characteristics with host and threat context. DNS filtering may block known names, but generated names and changing infrastructure complicate static lists. **Example:** A defender investigates a workstation that queries many random-looking names and correlates the activity with process and network telemetry. Related: [DNS tunneling](/glossary/dns-tunneling), [DNS filtering](/glossary/dns-filtering), [NXDOMAIN](/glossary/nxdomain), [DNS resolver](/glossary/dns-resolver) Read online: [/glossary/domain-generation-algorithm](/glossary/domain-generation-algorithm) ## DORA (Digital Operational Resilience Act) Category: Regulation & risk The Digital Operational Resilience Act (DORA) is a European Union regulation focused on digital operational resilience in the financial sector. It addresses how covered financial entities manage information and communication technology risk and related third-party dependencies. **Why it matters in practice:** DORA is relevant to resilience programs that consider technology services, disruptions, and oversight in financial operations. Its scope and duties depend on the organization and legal text, so a term entry is not a coverage analysis. In this glossary, “DORA Regulation” is treated as a synonym for this same act. **Example:** A financial technology team inventories a critical service dependency and sends its resilience review to the owner responsible for the organization’s DORA assessment. Related: [Third-Party Risk Management (TPRM)](/glossary/third-party-risk-management-tprm), [Tech Risk Management](/glossary/tech-risk-management), [Incident Response Plan](/glossary/incident-response-plan), [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management) Read online: [/glossary/dora](/glossary/dora) ## DORA Regulation Category: Regulation & risk DORA Regulation is another label for the Digital Operational Resilience Act (DORA). This glossary treats the two labels as referring to the same European Union regulation, not as separate instruments with different meanings. **Why it matters in practice:** The synonym is retained because people may search for either label, while one canonical entry avoids presenting the same act twice as separate law. The detail route for this label redirects to DORA. Readers should use the canonical entry and authoritative legal text for any scope or interpretation question. **Example:** A reader searching for “DORA Regulation” reaches the same canonical DORA entry rather than a second, conflicting summary. Related: [DORA (Digital Operational Resilience Act)](/glossary/dora), [Tech Risk Management](/glossary/tech-risk-management), [Incident Response Plan](/glossary/incident-response-plan), [Risk Register](/glossary/risk-register) Read online: [/glossary/dora](/glossary/dora) ## DPIA (Data Protection Impact Assessment) Category: Privacy & data A data protection impact assessment (DPIA) is a structured review of how a defined personal-data processing activity may affect people’s privacy. It records the processing, relevant risks, planned safeguards, and decisions under the process applicable to the organization. **Why it matters in practice:** A DPIA can bring privacy concerns into design and help teams explain why a processing choice is necessary and how risks are handled. Whether one is required and what it must contain depend on the applicable framework and facts. It should reflect the real processing, not a generic product description. **Example:** A team describes a new analytics flow, identifies the personal data and access roles involved, and records mitigations for risks found during review. Related: [AI DPIA](/glossary/ai-dpia), [Data Privacy](/glossary/data-privacy), [Data Mapping](/glossary/data-mapping), [Data Minimization](/glossary/data-minimization) Read online: [/glossary/data-protection-impact-assessment](/glossary/data-protection-impact-assessment) ## DSAR (Data Subject Access Request) Category: Privacy & data A data subject access request (DSAR) is a request by a person to exercise a data-related right, commonly to obtain access to personal information. The available right, response process, and terminology depend on the privacy framework and the facts of the request. **Why it matters in practice:** Handling a request typically involves intake, identity checks, locating records, applying relevant exceptions, and documenting the response. Teams need a clear route between service staff, system owners, and reviewers so information can be found without over-disclosing it. A DSAR process should not assume that every request has the same legal basis. **Example:** A support agent routes an access request to the privacy queue, where the team records the systems searched and the decision made about the response. Related: [Customer Data Rights](/glossary/customer-data-rights), [Data Privacy](/glossary/data-privacy), [General Data Protection Regulation (GDPR)](/glossary/gdpr), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment) Read online: [/glossary/data-subject-access-request](/glossary/data-subject-access-request) ## Egress filtering Category: Proxy & networking Egress filtering applies policy to traffic leaving a network or workload, such as limiting destination addresses, ports, protocols, or request attributes. It can be enforced at different layers, and the available signals depend on where the control is placed. **Why it matters in practice:** Outbound controls can reduce unwanted connections, but their effectiveness depends on coverage, rule quality, DNS behavior, and bypass paths. A network allowlist may not inspect application semantics, while a proxy may not see traffic that avoids it. Egress filtering is one control and does not establish complete SSRF protection. **Example:** A test workload is allowed to reach its approved proxy endpoint, while direct outbound connections are reviewed by the network policy. Related: [Firewall rule](/glossary/firewall-rule), [Server-side request forgery (SSRF)](/glossary/server-side-request-forgery), [IP allowlist](/glossary/ip-allowlist), [DNS filtering](/glossary/dns-filtering) Read online: [/glossary/egress-filtering](/glossary/egress-filtering) ## Enterprise Risk Management (ERM) Category: Regulation & risk Enterprise risk management (ERM) is an organization-wide approach to identifying, evaluating, responding to, and monitoring risks that may affect objectives. It gives leadership and operational teams a shared structure for discussing risk across functions rather than treating each concern in isolation. **Why it matters in practice:** ERM connects risk ownership, reporting, and decisions with an organization’s strategy and operating processes. Programs vary in method and maturity, and a common register does not make risks directly comparable without context. Technology, privacy, and AI risks may feed an ERM process while still requiring specialized analysis. **Example:** A risk owner presents a service dependency alongside financial and operational concerns in the organization’s regular enterprise risk review. Related: [Risk Register](/glossary/risk-register), [Tech Risk Management](/glossary/tech-risk-management), [Third-Party Risk Management (TPRM)](/glossary/third-party-risk-management-tprm), [GRC](/glossary/governance-risk-and-compliance-grc) Read online: [/glossary/enterprise-risk-management](/glossary/enterprise-risk-management) ## Envelope encryption Category: Credentials & security Envelope encryption protects data with a data-encryption key and then protects that key with another key, often managed by a key-management system. The encrypted data and wrapped key can be stored together, while the higher-level key controls access to decryption. **Why it matters in practice:** Separating data encryption from key-encryption operations can support centralized access control and key lifecycle management. The arrangement still depends on secure key policies, correct wrapping, and application authorization. It does not mean every request is encrypted end to end or that a compromised authorized process cannot read plaintext. **Example:** A service encrypts a stored credential with a generated data key, then asks its KMS to wrap that key before storage. Related: [AES-256-GCM](/glossary/aes-256-gcm), [Key management service (KMS)](/glossary/key-management-service), [Credential vault](/glossary/credential-vault), [Write-only secret](/glossary/write-only-secret) Read online: [/glossary/envelope-encryption](/glossary/envelope-encryption) ## EU AI Act Category: Regulation & risk The EU AI Act is a European Union regulation establishing a legal framework for artificial intelligence systems. It uses a risk-based structure and addresses topics such as system categories, responsibilities, and governance; its application depends on the relevant legal provisions and facts. **Why it matters in practice:** Organizations use the Act to frame questions about AI systems connected with the European Union. Classification and legal obligations cannot be inferred from a model name alone, and the legal text should be consulted for current interpretation. This entry is a general identifier, not an assessment of a product or provider. **Example:** A project owner records a system’s intended purpose and asks a qualified reviewer to determine which parts of the Act need analysis. Related: [AI Act High-Risk Systems](/glossary/ai-act-high-risk-systems), [AI Compliance](/glossary/ai-compliance), [AI Governance](/glossary/ai-governance), [AI Conformity Assessment](/glossary/ai-conformity-assessment) Read online: [/glossary/eu-ai-act](/glossary/eu-ai-act) ## Firewall mode Category: Proxy & networking Firewall mode is a proxy operating mode that evaluates configured request rules to determine whether traffic should be allowed, denied, or handled for review. Rules expressed in Common Expression Language can inspect attributes available to the proxy; the mode is not a claim of complete default-deny or SSRF protection. **Why it matters in practice:** Firewall evaluation controls policy decisions, while Auto-Auth configures how upstream credentials are inserted. HTTPS traffic that must be inspected for request attributes uses the proxy’s TLS inspection path and requires client trust in its CA. Rule coverage depends on the attributes and routes actually visible to the proxy. **Example:** A rule allows a test request to api.example.com only when its method and path match the team’s configured policy. Related: [Auto-Auth mode](/glossary/auto-auth-mode), [Firewall rule](/glossary/firewall-rule), [Common Expression Language (CEL)](/glossary/common-expression-language), [TLS inspection](/glossary/tls-inspection) Read online: [/glossary/firewall-mode](/glossary/firewall-mode) ## Firewall rule Category: Proxy & networking A firewall rule is a condition and action used to control whether traffic is allowed, denied, or routed for another decision. In an application proxy, the rule can evaluate only the request attributes and connection details that the proxy can observe. **Why it matters in practice:** Rule order, default behavior, protocol visibility, and error handling affect the outcome of a policy. HTTPS requests hidden inside opaque CONNECT cannot be evaluated by application path unless the proxy inspects TLS. A set of rules should be tested against expected and unexpected requests; it is not automatically a complete SSRF defense. **Example:** An administrator writes a rule that allows a specific request method for api.example.com and verifies that a different destination is handled as intended. Related: [Common Expression Language (CEL)](/glossary/common-expression-language), [Firewall mode](/glossary/firewall-mode), [Egress filtering](/glossary/egress-filtering), [Server-side request forgery (SSRF)](/glossary/server-side-request-forgery) Read online: [/glossary/firewall-rule](/glossary/firewall-rule) ## Forward proxy Category: Proxy & networking A forward proxy sits between a client and destinations the client wants to reach. The client sends requests to the proxy, which applies its configured routing or policy and makes the upstream connection; the destination generally sees the proxy’s outbound connection rather than a direct client connection. **Why it matters in practice:** Forward proxies are used to centralize outbound access, apply network policy, or mediate requests from applications. Their behavior depends on protocol support, authentication, and how traffic is handled. A forward proxy can be shared or dedicated, and its egress address is not necessarily the same as its listening address. **Example:** A command-line client is configured to send HTTP requests to a proxy endpoint, which then contacts api.example.com on the client’s behalf. Related: [Hyperproxy](/glossary/credential-injecting-forward-proxy), [Reverse proxy](/glossary/reverse-proxy), [HTTP proxy](/glossary/http-proxy), [Proxy IP](/glossary/proxy-ip) Read online: [/glossary/forward-proxy](/glossary/forward-proxy) ## Foundation Models Category: AI governance A foundation model is a machine-learning model trained on broad data that can be adapted or used for multiple downstream tasks. The term describes a model’s general-purpose role in a technical workflow, not a specific architecture, capability level, or quality guarantee. **Why it matters in practice:** Foundation models can be integrated through prompts, fine-tuning, retrieval, or other system components, and the surrounding application affects their behavior. Teams should assess the model and deployment context separately, including data, access, evaluation, and reliance. The model label does not decide how a legal framework classifies a system. **Example:** A team compares a general text model with a task-specific classifier before deciding which component should summarize internal support notes. Related: [AI Model Inventory](/glossary/ai-model-inventory), [AI Model Drift](/glossary/ai-model-drift), [AI Lifecycle Management](/glossary/ai-lifecycle-management), [AI Explainability](/glossary/ai-explainability) Read online: [/glossary/foundation-models](/glossary/foundation-models) ## General Data Protection Regulation (GDPR) Category: Privacy & data The General Data Protection Regulation (GDPR) is a European Union regulation governing the processing of personal data. It establishes a rights and obligations framework for activities within its scope; whether a specific organization or processing operation is covered requires legal analysis. **Why it matters in practice:** The GDPR is a common reference point for privacy programs, but a short summary cannot capture its definitions, territorial scope, exceptions, and interpretive materials. Organizations typically map processing and roles before selecting controls. This entry provides a general description and should not be treated as advice about a particular activity. **Example:** A service owner maps a customer-data flow and asks counsel to assess the organization’s role and the GDPR provisions relevant to that processing. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DSAR (Data Subject Access Request)](/glossary/data-subject-access-request), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment) Read online: [/glossary/gdpr](/glossary/gdpr) ## GRC Category: Regulation & risk Governance, risk, and compliance (GRC) is an umbrella approach for coordinating decision-making, risk oversight, and adherence to requirements across an organization. The acronym can refer to a program, operating model, or supporting tools rather than to one universal standard. **Why it matters in practice:** Connecting these functions can make ownership and reporting more consistent, while specialists still need room to assess technical and legal details. A GRC platform may organize records and workflows, but software alone does not create sound governance. Teams should clarify which program and responsibilities the term refers to. **Example:** A company routes a new vendor review through its GRC workflow, which assigns a risk owner and links the review evidence. Related: [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management), [Risk Register](/glossary/risk-register), [AI Compliance](/glossary/ai-compliance), [Third-Party Risk Management (TPRM)](/glossary/third-party-risk-management-tprm) Read online: [/glossary/governance-risk-and-compliance-grc](/glossary/governance-risk-and-compliance-grc) ## Guardian Agents Category: AI governance Guardian agents are software agents or agent-like controls intended to observe or constrain the actions of another agent. The label is used for a design pattern, not a standardized technical category; implementations vary in authority, visibility, and ability to intervene. **Why it matters in practice:** A monitoring agent can introduce its own failure modes, permissions, and dependencies, so its decisions need oversight just like the system it watches. Teams should define what signals it sees, what actions it can take, and how people can inspect or override those actions. A guardian design is not a complete safety guarantee. **Example:** A review component checks proposed outbound actions against a policy and sends an uncertain case to a person instead of silently approving it. Related: [Agent Governance](/glossary/agent-governance), [AI Safety](/glossary/ai-safety), [AI Accountability](/glossary/ai-accountability), [Responsible AI](/glossary/responsible-ai) Read online: [/glossary/guardian-agents](/glossary/guardian-agents) ## Host-scoped credentials Category: Credentials & security Host-scoped credentials are credentials configured for use only with a named destination host or host pattern. Scoping helps prevent a secret intended for one service from being attached to requests for an unrelated destination, subject to the matching rules of the implementation. **Why it matters in practice:** Correct scoping depends on parsing the request authority consistently, including port, scheme, redirects, and any permitted subdomains. Teams should test edge cases and avoid broad wildcard patterns they do not need. Host scoping narrows a credential’s intended use but does not prove that the destination itself is safe. **Example:** A vault binds one key to api.example.com, and a request to a different host does not receive that credential. Related: [Service binding](/glossary/service-binding), [Credential vault](/glossary/credential-vault), [Credential injection](/glossary/credential-injection), [Least privilege](/glossary/least-privilege) Read online: [/glossary/host-scoped-credentials](/glossary/host-scoped-credentials) ## HTTP proxy Category: Proxy & networking An HTTP proxy is a proxy that uses HTTP protocol conventions to receive and forward client requests. It can send ordinary HTTP requests onward or use CONNECT to establish a tunnel for another protocol, commonly TLS, depending on its implementation and configuration. **Why it matters in practice:** The name describes a protocol role and does not specify whether the proxy connection itself is encrypted. Credentials and request contents sent to an HTTP proxy need protection appropriate to the network. For HTTPS destinations, an ordinary CONNECT tunnel carries opaque TLS unless the proxy separately terminates or inspects it. **Example:** A client sends an HTTP request to its configured proxy, which makes the corresponding upstream request to api.example.com. Related: [HTTPS proxy](/glossary/https-proxy), [Forward proxy](/glossary/forward-proxy), [CONNECT tunnel](/glossary/connect-tunnel), [Proxy authentication](/glossary/proxy-authentication) Read online: [/glossary/http-proxy](/glossary/http-proxy) ## HTTPS proxy Category: Proxy & networking An HTTPS proxy uses TLS for the client-to-proxy connection. That transport protects the connection to the proxy; it is distinct from sending a request to an HTTPS destination through an HTTP proxy using CONNECT, where the destination TLS session runs inside the tunnel. **Why it matters in practice:** The two arrangements have different TLS endpoints and trust requirements. Encrypting the client-to-proxy hop does not automatically let the proxy read an HTTPS destination request, and it does not mean that the destination connection has been inspected. Clients need the right proxy endpoint and certificate validation for the selected topology. **Example:** A client first opens TLS to its HTTPS proxy, then asks it to establish a CONNECT tunnel to api.example.com. Related: [HTTP proxy](/glossary/http-proxy), [CONNECT tunnel](/glossary/connect-tunnel), [TLS inspection](/glossary/tls-inspection), [Certificate authority (CA)](/glossary/certificate-authority) Read online: [/glossary/https-proxy](/glossary/https-proxy) ## Human-in-the-loop approval (HITL) Category: AI governance Human-in-the-loop approval (HITL) is a workflow in which a person reviews or authorizes a system action before it proceeds. The person’s role, information, authority, and ability to reject or change the action determine whether the review is meaningful. **Why it matters in practice:** A human checkpoint can add judgment where automated confidence or policy checks are insufficient, but it can also become routine clicking if context is poor. Teams should define when review is required, what evidence is shown, and how decisions are recorded. Human approval does not guarantee that the action is correct or lawful. **Example:** A Hyperproxy firewall HITL rule holds a request for dashboard review so an operator can approve it before the sensitive upstream action proceeds. Related: [Agent Governance](/glossary/agent-governance), [Firewall mode](/glossary/firewall-mode), [Capability token](/glossary/capability-token), [Least privilege](/glossary/least-privilege) Read online: [/glossary/human-in-the-loop-approval](/glossary/human-in-the-loop-approval) ## Incident Response Plan Category: Regulation & risk An incident response plan documents how an organization prepares for, detects, assesses, contains, and recovers from security or operational incidents. It identifies roles, decision paths, communications, and practical steps that responders can follow under pressure. **Why it matters in practice:** Plans are useful only when they reflect real systems and people, and when exercises reveal unclear handoffs before an incident occurs. Response procedures often connect technical investigation with legal, privacy, customer, and leadership decisions. The plan should be reviewed as tools, dependencies, and responsibilities change. **Example:** A tabletop exercise simulates suspicious outbound traffic and tests how an on-call engineer reaches the service owner and incident lead. Related: [Tech Risk Management](/glossary/tech-risk-management), [NIS2 Directive](/glossary/nis2-directive), [DORA (Digital Operational Resilience Act)](/glossary/dora), [Risk Register](/glossary/risk-register) Read online: [/glossary/incident-response-plan](/glossary/incident-response-plan) ## Indonesia Personal Data Protection Law Category: Privacy & data Indonesia’s Personal Data Protection Law is the country’s national legal framework for personal-data processing. Its interpretation and application are shaped by the law and related legal materials, together with the organization, people, and processing activity being assessed. **Why it matters in practice:** Organizations use the law as a reference when reviewing data practices connected with Indonesia. A careful analysis should rely on current authoritative materials rather than assuming that requirements match those in another country. This general glossary entry does not enumerate rights, deadlines, or exceptions. **Example:** A team documents which personal information a regional service handles and asks its legal reviewer to assess the relevant Indonesian framework. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/indonesia-personal-data-protection-law](/glossary/indonesia-personal-data-protection-law) ## Internet Content Adaptation Protocol (ICAP) Category: Proxy & networking Internet Content Adaptation Protocol (ICAP) is a protocol for an HTTP proxy to delegate content adaptation or related processing to an external service. The proxy sends a request or response context to an ICAP server, which returns a result according to the configured service. **Why it matters in practice:** ICAP defines an integration boundary rather than the policy or safety of the adaptation service. Deployments need to consider what content leaves the proxy, how it is protected, and what happens when the service is unavailable. Support for ICAP is product-specific and should not be assumed from the term alone. **Example:** An HTTP proxy configured for an ICAP service sends a request body for a scanning decision before forwarding it to api.example.com. Related: [HTTP proxy](/glossary/http-proxy), [Forward proxy](/glossary/forward-proxy), [Data plane](/glossary/data-plane), [TLS inspection](/glossary/tls-inspection) Read online: [/glossary/internet-content-adaptation-protocol](/glossary/internet-content-adaptation-protocol) ## IP allowlist Category: Proxy & networking An IP allowlist is a rule set that permits connections from specified IP addresses or ranges and rejects other sources at the enforcing boundary. It is a network access control, not user authentication, and the observed source may be a NAT gateway or intermediary rather than an individual device. **Why it matters in practice:** Allowlist entries need maintenance when addresses or network paths change. Teams should understand which address the service evaluates and avoid treating a permitted network as proof of a trusted user or request. Layering an allowlist with identity and application authorization provides distinct controls. **Example:** An operator allows a test gateway’s documented egress address to reach a proxy and separately requires each client to authenticate. Related: [CIDR notation](/glossary/cidr-notation), [Proxy IP](/glossary/proxy-ip), [Static IP address](/glossary/static-ip-address), [Least privilege](/glossary/least-privilege) Read online: [/glossary/ip-allowlist](/glossary/ip-allowlist) ## Key management service (KMS) Category: Credentials & security A key-management service (KMS) provides controlled operations for creating, storing, using, and managing cryptographic keys. Applications may request operations such as encrypting data or wrapping a data key without directly handling the long-term key material. **Why it matters in practice:** A KMS can centralize identity checks, audit events, and key lifecycle controls, but its protection depends on policy configuration and the security of callers. Availability and recovery design matter because applications may need the service to access protected data. KMS use does not automatically make an application or its secrets secure. **Example:** A service identity requests a data-key operation from its configured KMS, and the service records the operation for later review. Related: [Envelope encryption](/glossary/envelope-encryption), [AES-256-GCM](/glossary/aes-256-gcm), [Credential vault](/glossary/credential-vault), [Post-quantum cryptography](/glossary/post-quantum-cryptography) Read online: [/glossary/key-management-service](/glossary/key-management-service) ## Least privilege Category: Credentials & security Least privilege is the practice of granting an identity or component only the permissions needed for its defined task. Permissions should be scoped by action, resource, and context where possible, then reviewed as responsibilities change. **Why it matters in practice:** Narrow permissions can reduce the impact of mistakes or compromised credentials, but they require an accurate view of what a workflow needs. Teams should validate the policy with representative actions and ensure there is a safe process for exceptions. Least privilege is a design principle, not a one-time configuration label. **Example:** A worker receives access to one test service credential instead of permission to read every secret in the organization. Related: [Service binding](/glossary/service-binding), [Host-scoped credentials](/glossary/host-scoped-credentials), [Credential vault](/glossary/credential-vault), [IP allowlist](/glossary/ip-allowlist) Read online: [/glossary/least-privilege](/glossary/least-privilege) ## Malaysia Personal Data Protection Act (PDPA) Category: Privacy & data Malaysia’s Personal Data Protection Act (PDPA) is a national law concerning personal-data processing in the context defined by the statute. Its scope and obligations depend on the current legal text, related requirements, and the facts of the processing activity. **Why it matters in practice:** A review involving Malaysia should distinguish this Act from similarly abbreviated privacy laws elsewhere. Teams need to identify the organization, data, and processing in question before relying on a summary. This entry gives the law’s basic identity and does not state a complete set of obligations or determine applicability. **Example:** A company lists the personal data used by a customer-support service in Malaysia and requests a local legal review of its handling. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/malaysia-personal-data-protection-act-pdpa](/glossary/malaysia-personal-data-protection-act-pdpa) ## ML-DSA Category: Credentials & security ML-DSA is a post-quantum digital-signature algorithm standardized by NIST. It enables a verifier to check that a signed message was authorized by the holder of a signing key and has not changed; it does not encrypt the message or establish a shared secret. **Why it matters in practice:** Signatures support authenticity and integrity when keys and verification policies are managed correctly. ML-DSA therefore has a different role from ML-KEM, which establishes shared secret material. A signature does not prove that a message is truthful or that the signing key was protected from misuse. **Example:** A release process verifies an ML-DSA signature on a package before treating the package as signed by its expected publisher. Related: [Post-quantum cryptography](/glossary/post-quantum-cryptography), [ML-KEM](/glossary/ml-kem), [Key management service (KMS)](/glossary/key-management-service), [AES-256-GCM](/glossary/aes-256-gcm) Read online: [/glossary/ml-dsa](/glossary/ml-dsa) ## ML-KEM Category: Credentials & security ML-KEM is a post-quantum key-encapsulation mechanism standardized by NIST for establishing a shared secret between parties. It is a key-establishment algorithm, not an encryption mode for application data; a protocol uses the resulting secret with an appropriate symmetric cipher. **Why it matters in practice:** Using ML-KEM requires compatible implementations and a protocol that authenticates the exchange as needed for the application. The algorithm’s role should not be confused with digital signatures or bulk data encryption. System security also depends on implementation, key handling, downgrade behavior, and the surrounding protocol. **Example:** Two compatible endpoints use ML-KEM to establish shared key material, then use a separate authenticated cipher for a message. Related: [Post-quantum cryptography](/glossary/post-quantum-cryptography), [ML-DSA](/glossary/ml-dsa), [AES-256-GCM](/glossary/aes-256-gcm), [Key management service (KMS)](/glossary/key-management-service) Read online: [/glossary/ml-kem](/glossary/ml-kem) ## Model Risk Management (MRM) Category: Regulation & risk Model risk management (MRM) is the process of identifying and controlling risks that arise when a model is developed, implemented, or used to inform decisions. It can include independent review, testing, documentation, monitoring, and governance appropriate to the model’s role. **Why it matters in practice:** A model may be technically correct yet misused, poorly implemented, or unsuitable for a particular decision. MRM helps organizations make assumptions, limitations, and oversight visible. Practices vary across industries and frameworks, so a model-risk label should not be mistaken for a universal regulatory rule. **Example:** A reviewer checks a forecasting model’s assumptions, implementation, and performance monitoring before the business relies on its output. Related: [AI Risk Management](/glossary/ai-risk-management), [AI Model Drift](/glossary/ai-model-drift), [AI Governance](/glossary/ai-governance), [Risk Register](/glossary/risk-register) Read online: [/glossary/model-risk-management](/glossary/model-risk-management) ## NIS2 Directive Category: Regulation & risk The NIS2 Directive is a European Union directive concerning cybersecurity and resilience for covered entities in specified sectors. It establishes a framework that member states implement through national law, so the detailed rules relevant to an organization may depend on local implementation. **Why it matters in practice:** NIS2 is used in cybersecurity and risk discussions, but the directive’s title alone does not establish whether an entity is in scope. Organizations need to consider the relevant sector, entity characteristics, national measures, and current legal guidance. This summary intentionally avoids listing deadlines or asserting coverage. **Example:** A security team asks local counsel to check its organization’s sector and national implementation before changing its incident-governance process. Related: [Incident Response Plan](/glossary/incident-response-plan), [Tech Risk Management](/glossary/tech-risk-management), [DORA (Digital Operational Resilience Act)](/glossary/dora), [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management) Read online: [/glossary/nis2-directive](/glossary/nis2-directive) ## NIST AI Risk Management Framework (AI RMF) Category: AI governance The NIST AI Risk Management Framework (AI RMF) is a voluntary resource from the U.S. National Institute of Standards and Technology for organizing AI risk management. It provides functions and guidance that organizations can adapt to their context rather than a certification or legal determination. **Why it matters in practice:** The framework gives teams a shared vocabulary for governing, mapping, measuring, and managing AI risks. Its usefulness depends on applying the guidance to a defined system and documenting decisions. Adoption does not prove that a system is safe, compliant, or free from risk. **Example:** A model team uses the framework’s functions to structure a review of intended use, evaluation evidence, and ongoing monitoring responsibilities. Related: [AI Risk Management](/glossary/ai-risk-management), [AI Governance](/glossary/ai-governance), [AI Safety](/glossary/ai-safety), [AI Lifecycle Management](/glossary/ai-lifecycle-management) Read online: [/glossary/nist-ai-risk-management](/glossary/nist-ai-risk-management) ## NXDOMAIN Category: Proxy & networking NXDOMAIN is a DNS response code indicating that the queried domain name does not exist in the relevant DNS namespace. It is different from an existing name that lacks a requested record type, and it describes a lookup result rather than an application-level HTTP error. **Why it matters in practice:** NXDOMAIN responses can occur because of a typo, stale configuration, an unregistered name, or a filtering policy that intentionally returns that code. Repeated failures may be useful operational telemetry, but the code alone does not explain why resolution failed. Resolver logs and the query path provide needed context. **Example:** A client asks for a misspelled api.example.com name and receives NXDOMAIN because no such DNS name is registered. Related: [DNS resolver](/glossary/dns-resolver), [DNS filtering](/glossary/dns-filtering), [Domain generation algorithm (DGA)](/glossary/domain-generation-algorithm), [Private DNS server](/glossary/private-dns-server) Read online: [/glossary/nxdomain](/glossary/nxdomain) ## Philippines Data Privacy Act (DPA) Category: Privacy & data The Philippines Data Privacy Act is a national law concerning the protection and processing of personal information in the Philippines. The statute is commonly identified as Republic Act No. 10173; applicable interpretation depends on the legal text and circumstances. **Why it matters in practice:** Organizations use the Act as a reference when reviewing personal-information practices connected with the Philippines. A sound assessment considers the relevant roles and processing rather than relying on the title alone. This description provides a general identity and does not list all rights, exceptions, or implementing requirements. **Example:** A privacy team maps a customer-support workflow connected with the Philippines and asks a qualified reviewer to assess the data practices. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/philippines-data-privacy-act-dpa](/glossary/philippines-data-privacy-act-dpa) ## Post-quantum cryptography Category: Credentials & security Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both conventional and sufficiently capable quantum computers. It includes different purposes, such as key establishment and digital signatures; the term does not mean every algorithm or system is invulnerable. **Why it matters in practice:** Migration work must consider protocol support, key sizes, interoperability, implementation quality, and the data’s confidentiality horizon. Standardized algorithms address particular cryptographic problems rather than replacing all security controls. Teams should distinguish key-establishment mechanisms from signatures and avoid promising “unbreakable” encryption. **Example:** An engineering team tests whether its client and service can negotiate a supported post-quantum key-establishment method before changing production protocols. Related: [ML-KEM](/glossary/ml-kem), [ML-DSA](/glossary/ml-dsa), [Key management service (KMS)](/glossary/key-management-service), [AES-256-GCM](/glossary/aes-256-gcm) Read online: [/glossary/post-quantum-cryptography](/glossary/post-quantum-cryptography) ## Privacy-Enhancing Technologies (PETs) Category: Privacy & data Privacy-enhancing technologies (PETs) are technical methods designed to reduce exposure of personal or sensitive information while enabling a defined computation or use. Examples vary widely, from data separation to cryptographic techniques; no single tool removes every privacy risk. **Why it matters in practice:** PETs can help teams explore designs that limit direct access to raw information, but the surrounding workflow still matters. Selection requires understanding participants, threat assumptions, output risks, and operational cost. A technique should be evaluated for the specific use rather than treated as a blanket privacy certification. **Example:** Two research teams compute a combined statistic using a privacy-preserving protocol instead of exchanging each participant’s raw records. Related: [Data Minimization](/glossary/data-minimization), [Data Privacy](/glossary/data-privacy), [Data Classification](/glossary/data-classification), [Data Discovery](/glossary/data-discovery) Read online: [/glossary/privacy-enhancing-technologies-pets](/glossary/privacy-enhancing-technologies-pets) ## Private DNS server Category: Proxy & networking A private DNS server resolves names for a private network or a defined set of clients. It can answer from internal zones, forward queries to another resolver, or apply organization-specific policy, but its privacy and security depend on the network and configuration around it. **Why it matters in practice:** Private resolution helps services find internal resources without publishing every name in public DNS. Administrators need to consider who can query the server, which upstreams receive forwarded questions, and how records are maintained. Private DNS does not mean queries are automatically encrypted or individually authenticated. **Example:** A service inside a test network asks its configured resolver for an internal service name that is not published in public DNS. Related: [DNS resolver](/glossary/dns-resolver), [DNS filtering](/glossary/dns-filtering), [DNS over HTTPS (DoH)](/glossary/dns-over-https), [NXDOMAIN](/glossary/nxdomain) Read online: [/glossary/private-dns-server](/glossary/private-dns-server) ## Proxy authentication Category: Credentials & security Proxy authentication is the process by which a client proves its identity or presents an access credential to a proxy. It governs access to the proxy itself and is distinct from the upstream credential that the proxy may send to a destination API. **Why it matters in practice:** HTTP proxy authentication commonly uses a proxy-specific challenge and the Proxy-Authorization header. Deployments should protect credentials in transit and avoid treating successful proxy login as authorization for every destination or action. Proxy authentication and upstream API authorization are separate trust decisions. **Example:** A client authenticates to its proxy with a proxy credential, then the proxy uses a different configured secret when contacting api.example.com. Related: [Proxy-Authorization header](/glossary/proxy-authorization-header), [Authorization header](/glossary/authorization-header), [Bearer token](/glossary/bearer-token), [Hyperproxy](/glossary/credential-injecting-forward-proxy) Read online: [/glossary/proxy-authentication](/glossary/proxy-authentication) ## Proxy IP Category: Proxy & networking A proxy IP is an IP address assigned to or used to reach a proxy listener. It is distinct from the client’s source IP and may also differ from the egress IP that a destination sees when the proxy makes an upstream connection. **Why it matters in practice:** The same proxy can have separate inbound and outbound network identities depending on its deployment. Logs may record client addresses, proxy listener addresses, and upstream addresses for different purposes. An IP address alone does not identify a person, authenticate a request, or prove that traffic came from a particular application. **Example:** An access record shows a client IP connecting to the proxy, while a destination observes the proxy’s separate egress address. Related: [Forward proxy](/glossary/forward-proxy), [Static IP address](/glossary/static-ip-address), [Dedicated proxy](/glossary/dedicated-proxy), [IP allowlist](/glossary/ip-allowlist) Read online: [/glossary/proxy-ip](/glossary/proxy-ip) ## Proxy port Category: Proxy & networking A proxy port is a numbered transport endpoint on which a proxy process accepts connections. A client combines the proxy’s address and port to reach that listener; the port identifies a service endpoint, not a separate machine or public IP address. **Why it matters in practice:** Several listeners can use different ports on one address for protocol or configuration reasons. Changing a port does not automatically allocate another IP, alter a destination’s address, or guarantee isolation. Network rules, proxy configuration, and the client’s connection settings determine whether a port is reachable and how it behaves. **Example:** An application connects to the proxy’s configured host and listener port; adding a second listener does not create a second proxy IP. Related: [Proxy IP](/glossary/proxy-ip), [HTTP proxy](/glossary/http-proxy), [HTTPS proxy](/glossary/https-proxy), [Forward proxy](/glossary/forward-proxy) Read online: [/glossary/proxy-port](/glossary/proxy-port) ## Proxy-Authorization header Category: Credentials & security Proxy-Authorization is an HTTP request header used to present credentials to a proxy that has challenged the client. It is intended for the next proxy hop, not as the origin server’s Authorization header, and its confidentiality depends on the client-to-proxy connection. **Why it matters in practice:** The header belongs to proxy access control and should not be confused with a credential intended for an upstream API. Intermediaries need to handle it according to HTTP semantics and remove or protect it where appropriate. A proxy must not blindly forward proxy credentials to an origin server. **Example:** A client sends Proxy-Authorization to its authenticated proxy while keeping the origin Authorization field reserved for api.example.com. Related: [Proxy authentication](/glossary/proxy-authentication), [Authorization header](/glossary/authorization-header), [Bearer token](/glossary/bearer-token), [Forward proxy](/glossary/forward-proxy) Read online: [/glossary/proxy-authorization-header](/glossary/proxy-authorization-header) ## Responsible AI Category: AI governance Responsible AI is an approach to designing, developing, and using artificial intelligence with attention to people, risks, accountability, and the intended purpose. It is a broad organizational concept rather than one technical standard or a guarantee about system outcomes. **Why it matters in practice:** Organizations translate responsible-AI principles into concrete decisions about data, evaluation, human oversight, transparency, and operation. Different values can conflict, so teams should explain how they set priorities and review results. A policy statement without accountable owners and evidence may not change the way a system is used. **Example:** A product review records who may be affected by an automated summary and what human check occurs before it is shared. Related: [AI Governance](/glossary/ai-governance), [AI Accountability](/glossary/ai-accountability), [Trustworthy AI](/glossary/trustworthy-ai), [AI Safety](/glossary/ai-safety) Read online: [/glossary/responsible-ai](/glossary/responsible-ai) ## Reverse proxy Category: Proxy & networking A reverse proxy accepts requests on behalf of one or more backend services and forwards them to an appropriate origin. It commonly provides a stable front door for routing, TLS termination, or load distribution, while clients address the proxy rather than selecting a backend directly. **Why it matters in practice:** A reverse proxy faces incoming clients, whereas a forward proxy is typically selected by clients for outbound destinations. The distinction is about which side the proxy represents, not whether it encrypts traffic or authenticates users. Security depends on the deployment, backend trust, and request handling rules. **Example:** A browser requests a company service endpoint, and the reverse proxy routes that request to the selected application instance. Related: [Forward proxy](/glossary/forward-proxy), [HTTP proxy](/glossary/http-proxy), [HTTPS proxy](/glossary/https-proxy), [TLS inspection](/glossary/tls-inspection) Read online: [/glossary/reverse-proxy](/glossary/reverse-proxy) ## Risk Register Category: Regulation & risk A risk register is a structured record of identified risks, their context, owners, assessment, and planned responses. Teams use it to track decisions over time; the fields and scoring method vary according to the organization and the risks being managed. **Why it matters in practice:** A register can make ownership and follow-up visible, but a numeric score is not a complete explanation of uncertainty or impact. Entries should connect to evidence and be reviewed when assumptions change. A register is one tool within risk management, not a substitute for specialist analysis or effective controls. **Example:** A service owner records a dependency failure scenario, names a response owner, and links the mitigation to a recovery exercise. Related: [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management), [Tech Risk Management](/glossary/tech-risk-management), [Third-Party Risk Management (TPRM)](/glossary/third-party-risk-management-tprm), [Incident Response Plan](/glossary/incident-response-plan) Read online: [/glossary/risk-register](/glossary/risk-register) ## Secret expiry Category: Credentials & security Secret expiry is a configured point after which a secret should no longer be accepted or used. The effect depends on the system enforcing the expiry; a date stored as metadata does not revoke the credential at an upstream service unless that service or workflow acts on it. **Why it matters in practice:** Expiry can reduce reliance on long-lived credentials, but dependent jobs need a replacement and a clear renewal owner. Notifications, revocation, and application behavior are separate parts of the lifecycle. Teams should test what happens after expiry instead of assuming every client will fail safely. **Example:** A service owner receives an expiry notice, provisions a replacement for api.example.com, and verifies the integration before retiring the old value. Related: [Credential rotation](/glossary/credential-rotation), [Credential vault](/glossary/credential-vault), [Write-only secret](/glossary/write-only-secret), [API key](/glossary/api-key) Read online: [/glossary/secret-expiry](/glossary/secret-expiry) ## Secret placeholder Category: Credentials & security A secret placeholder is a marker in a request or configuration that a trusted component recognizes and replaces with a stored credential. It allows a client to refer to a secret without containing its plaintext value, but only works when the request reaches a component configured to perform that substitution. **Why it matters in practice:** Placeholders need an unambiguous syntax, permitted destination, and matching secret binding. For HTTPS requests, substitution inside an encrypted request requires the proxy to inspect the TLS connection; an opaque tunnel does not reveal the application header or body. A placeholder is not itself a credential or encryption mechanism. **Example:** A test client sends Authorization: Bearer {$SECRET_NAME} to api.example.com; the proxy resolves the marker to its bound secret without putting a live key in client code. Related: [Credential injection](/glossary/credential-injection), [Credential vault](/glossary/credential-vault), [Host-scoped credentials](/glossary/host-scoped-credentials), [API key](/glossary/api-key) Read online: [/glossary/secret-placeholder](/glossary/secret-placeholder) ## Secure share Category: Credentials & security A secure share is Hyperproxy’s expiring, use-limited proxy capability: it lets a recipient use an approved proxy path without receiving the stored upstream key. The share token itself is a sensitive bearer credential. **Why it matters in practice:** A share delegates a defined proxy capability without exposing the stored upstream API credential, and expiry or use limits bound how long that delegation remains available. Anyone holding the share token may be able to use its permissions, so the token itself needs protection and revocation planning. **Example:** An operator creates a short-lived share for a test proxy and sends its capability through an approved channel to a teammate. Related: [Capability token](/glossary/capability-token), [Bearer token](/glossary/bearer-token), [Credential vault](/glossary/credential-vault), [Least privilege](/glossary/least-privilege) Read online: [/glossary/secure-share](/glossary/secure-share) ## Server-side request forgery (SSRF) Category: Credentials & security Server-side request forgery (SSRF) is a vulnerability in which an application can be induced to make a network request chosen or influenced by an attacker. The risk depends on what destinations the server can reach, what response data is exposed, and what authority the application carries. **Why it matters in practice:** Defenses often combine strict destination validation, network segmentation, safe URL handling, and controls over redirects and name resolution. A proxy or egress filter can contribute only when the application’s traffic reliably passes through it and rules cover the relevant cases. No single generic filter should be described as complete SSRF protection. **Example:** A server accepts a user-supplied URL, so its team tests whether a request to an unintended address can be made through the normal application path. Related: [Egress filtering](/glossary/egress-filtering), [Firewall rule](/glossary/firewall-rule), [DNS resolver](/glossary/dns-resolver), [Least privilege](/glossary/least-privilege) Read online: [/glossary/server-side-request-forgery](/glossary/server-side-request-forgery) ## Service binding Category: Credentials & security A service binding associates a stored credential or policy with a named service context, such as an approved upstream host or application. The binding defines where a secret may be used; its exact matching and enforcement behavior depend on the system implementing it. **Why it matters in practice:** Bindings make secret use more specific than granting an application access to an unrestricted collection of credentials. They should be reviewed alongside destination matching, request fields, and the client identity that invokes them. A binding can reduce accidental cross-service use, but does not replace broader network and authorization controls. **Example:** An administrator binds a credential to api.example.com, selects the Authorization header and Bearer format, then verifies the request uses that service binding. Related: [Credential vault](/glossary/credential-vault), [Host-scoped credentials](/glossary/host-scoped-credentials), [Secret placeholder](/glossary/secret-placeholder), [Least privilege](/glossary/least-privilege) Read online: [/glossary/service-binding](/glossary/service-binding) ## Sidecar Category: Proxy & networking A sidecar is a helper process or container deployed alongside an application to provide a supporting capability. A sidecar proxy can handle network traffic for the application, allowing some routing or policy behavior to be managed outside the application’s own code. **Why it matters in practice:** Sidecars can simplify integration across services, but add another component to deploy, secure, observe, and update. Their presence does not guarantee that all application traffic passes through them; routing and bypass paths must be verified. Teams should define the boundary between the application, sidecar, and control system. **Example:** A workload sends outbound requests through a local sidecar proxy configured as its network gateway. Related: [Forward proxy](/glossary/forward-proxy), [Control plane](/glossary/control-plane), [Data plane](/glossary/data-plane), [HTTP proxy](/glossary/http-proxy) Read online: [/glossary/sidecar](/glossary/sidecar) ## Singapore Personal Data Protection Act (PDPA) Category: Privacy & data Singapore’s Personal Data Protection Act (PDPA) is a national law that governs aspects of private organizations’ handling of personal data. Its requirements and application depend on the current legal framework, organizational role, and processing activity. **Why it matters in practice:** The Singapore PDPA should not be confused with other laws that share the PDPA abbreviation. Organizations consider it when reviewing personal-data practices connected with Singapore and consult current authoritative materials for interpretation. This entry provides a broad identification, not a complete compliance checklist or conclusion. **Example:** A regional service team labels its Singapore data flows clearly and asks a reviewer to assess which requirements apply to the specific activity. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DSAR (Data Subject Access Request)](/glossary/data-subject-access-request), [Data Minimization](/glossary/data-minimization) Read online: [/glossary/singapore-personal-data-protection-act-pdpa](/glossary/singapore-personal-data-protection-act-pdpa) ## South Korea AI Basic Act Category: Regulation & risk South Korea’s AI Basic Act is a national framework for developing and using artificial intelligence. It combines support for AI adoption with governance requirements for areas such as transparency, safety, high-impact AI, and generative AI; the applicable duties depend on the system and legal framework. **Why it matters in practice:** Organizations assessing AI activity connected with South Korea need to distinguish the Act’s requirements from internal policies and other laws. Legal interpretation may depend on the system and activity, so teams should check current sources rather than extrapolate from a general summary. This glossary avoids unverified scope claims or timelines. **Example:** A company records a proposed AI use in South Korea and asks a local legal reviewer which parts of the Act warrant closer analysis. Related: [EU AI Act](/glossary/eu-ai-act), [AI Act High-Risk Systems](/glossary/ai-act-high-risk-systems), [AI Governance](/glossary/ai-governance), [AI Compliance](/glossary/ai-compliance) Read online: [/glossary/south-korea-ai-basic-act](/glossary/south-korea-ai-basic-act) ## Static IP address Category: Proxy & networking A static IP address is an address intended to remain assigned to a network interface or service over time rather than changing with each connection or lease. The assignment and continuity depend on the provider and network configuration. **Why it matters in practice:** A stable address can simplify allowlists and operational references, but it does not encrypt traffic, authenticate a client, or identify a human user. A proxy’s listener address and its egress address may be different. Teams should confirm which address is stable and how reassignment is handled. **Example:** An administrator records the proxy’s documented egress IP for an upstream allowlist and separately records the inbound listener address. Related: [Proxy IP](/glossary/proxy-ip), [Dedicated proxy](/glossary/dedicated-proxy), [IP allowlist](/glossary/ip-allowlist), [CIDR notation](/glossary/cidr-notation) Read online: [/glossary/static-ip-address](/glossary/static-ip-address) ## Tech Risk Management Category: Regulation & risk Technology risk management is the process of identifying, assessing, treating, and monitoring risks related to technology systems and their use. It can cover availability, security, change, data, suppliers, and operational dependencies according to an organization’s needs. **Why it matters in practice:** Technology risks can affect business services even when individual components appear healthy, because systems depend on people, vendors, and shared infrastructure. A useful process connects technical evidence with accountable owners and operational decisions. It complements specialized disciplines such as cybersecurity and privacy rather than replacing them. **Example:** An operations team assesses how a failed identity provider could affect access to a customer service and records a recovery owner. Related: [Incident Response Plan](/glossary/incident-response-plan), [Risk Register](/glossary/risk-register), [Third-Party Risk Management (TPRM)](/glossary/third-party-risk-management-tprm), [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management) Read online: [/glossary/tech-risk-management](/glossary/tech-risk-management) ## Thailand Personal Data Protection Act Category: Privacy & data Thailand’s Personal Data Protection Act (PDPA) is a national law concerning personal-data processing in Thailand. Its application and interpretation depend on the current legal framework and the circumstances of the organization and activity being assessed. **Why it matters in practice:** Because several jurisdictions use the abbreviation PDPA, naming the country is important when discussing obligations or controls. Organizations should consult authoritative Thai legal materials and qualified advice for current requirements. This glossary entry identifies the law generally and does not state deadlines, exceptions, or a coverage conclusion. **Example:** A privacy lead labels a regional data-flow record “Thailand PDPA” so it is not confused with another country’s similarly abbreviated law. Related: [Data Privacy](/glossary/data-privacy), [Customer Data Rights](/glossary/customer-data-rights), [DPIA (Data Protection Impact Assessment)](/glossary/data-protection-impact-assessment), [Data Mapping](/glossary/data-mapping) Read online: [/glossary/thailand-personal-data-protection-act-pdpa](/glossary/thailand-personal-data-protection-act-pdpa) ## Third-Party Risk Management (TPRM) Category: Regulation & risk Third-party risk management (TPRM) is the process of understanding and addressing risks introduced by suppliers, service providers, and other external parties. It can include due diligence, contract review, access decisions, monitoring, and plans for changing or ending a relationship. **Why it matters in practice:** External services can handle data or support critical operations, so assessment should reflect the relationship’s actual access and importance. A questionnaire alone may not capture technical dependencies or ongoing changes. TPRM connects procurement and security work with owners who can make decisions about residual risk. **Example:** Before connecting a provider to a test environment, an organization reviews its data access, support model, and exit plan with the service owner. Related: [Vendor Risk Assessment](/glossary/vendor-risk-assessment), [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management), [Risk Register](/glossary/risk-register), [Data Privacy](/glossary/data-privacy) Read online: [/glossary/third-party-risk-management-tprm](/glossary/third-party-risk-management-tprm) ## TLS inspection Category: Credentials & security TLS inspection is the termination of an encrypted TLS connection by an intermediary so it can inspect or modify the protected application traffic. A client must trust the intermediary’s certificate authority for the inspected connection; inspection changes the end-to-end trust boundary and should be explicit. **Why it matters in practice:** Hyperproxy uses TLS inspection for HTTPS placeholder substitution in Auto-Auth and HTTPS request-level rule evaluation in Firewall mode. Clients must trust the proxy CA for inspected connections in either mode. An opaque CONNECT tunnel cannot expose encrypted HTTP headers for rewriting; plain HTTP does not need TLS inspection. **Example:** A test client trusts the proxy CA, establishes an inspected connection, and the proxy reads the request header before applying the selected mode. Related: [CONNECT tunnel](/glossary/connect-tunnel), [Certificate authority (CA)](/glossary/certificate-authority), [HTTPS proxy](/glossary/https-proxy), [Credential injection](/glossary/credential-injection) Read online: [/glossary/tls-inspection](/glossary/tls-inspection) ## Trustworthy AI Category: AI governance Trustworthy AI describes artificial intelligence designed and operated in ways that people can reasonably rely on for a stated purpose. The term commonly brings together reliability, accountability, transparency, and attention to affected people, but it is not one measurable property shared by every system. **Why it matters in practice:** Trust depends on evidence, communication, system limits, and the choices made around deployment. Teams should explain which qualities they evaluate and for whom a system is intended. A claim that AI is trustworthy should not be inferred from a framework name, vendor statement, or one successful test. **Example:** A team publishes a model’s intended use and known limitations, then gives operators a way to report outputs that do not fit the task. Related: [Responsible AI](/glossary/responsible-ai), [AI Governance](/glossary/ai-governance), [AI Accountability](/glossary/ai-accountability), [AI Safety](/glossary/ai-safety) Read online: [/glossary/trustworthy-ai](/glossary/trustworthy-ai) ## Vendor Risk Assessment Category: Regulation & risk A vendor risk assessment is a review of risks associated with a particular supplier and the services it provides. It considers relevant factors such as data access, security practices, operational dependency, and the organization’s ability to respond to a disruption. **Why it matters in practice:** The depth of review should match the vendor relationship rather than rely on one questionnaire for every supplier. Evidence needs interpretation, and identified issues should have owners and decisions. Assessment is one part of managing a relationship across selection, use, change, and exit. **Example:** A procurement reviewer compares a supplier’s security evidence with the data and system access requested for a proposed integration. Related: [Third-Party Risk Management (TPRM)](/glossary/third-party-risk-management-tprm), [Enterprise Risk Management (ERM)](/glossary/enterprise-risk-management), [Risk Register](/glossary/risk-register), [Incident Response Plan](/glossary/incident-response-plan) Read online: [/glossary/vendor-risk-assessment](/glossary/vendor-risk-assessment) ## Write-only secret Category: Credentials & security A write-only secret is a sensitive value that a management interface accepts but does not later display in plaintext. The design limits one exposure path, while service access, storage, backups, logs, and replacement workflows still require appropriate protection. **Why it matters in practice:** Write-only handling helps prevent accidental redisclosure when an operator revisits a settings page. It should provide clear confirmation and a safe way to replace a value without pretending the system cannot use it. Users need to understand that hiding a secret after entry is not the same as cryptographic erasure. **Example:** An administrator submits a new API key, sees that a value is stored, and can replace it later without reading the original plaintext. Related: [Credential vault](/glossary/credential-vault), [Credential rotation](/glossary/credential-rotation), [Secret expiry](/glossary/secret-expiry), [API key](/glossary/api-key) Read online: [/glossary/write-only-secret](/glossary/write-only-secret)