Control CoreDocs

📌 Dynamic Context Management

Use real-time context—user, time, location, risk, business state—from Policy Information Points (PIPs) to make allow/deny and filtering decisions. Control Core policies can adapt to current conditions instead of relying only on static roles or attributes.

📌 Definition

Dynamic context management with Control Core means:

  • Feeding live data from PIPs (identity providers, HR, risk systems, consent stores, etc.) into policy evaluation.
  • Writing policies that depend on that context: time and location, risk scores, approval status, training completion, or business rules.
  • Enforcing at the Bouncer (PEP) so every request is evaluated with up-to-date context—supporting data masking, filtering, and access control that adapts to the situation.

Only product concepts (PAP, PEP, PIP, PDP, Control Plane, Bouncer) are used; no internal architecture or component names.

Context in, decision out

Click to enlarge

PIPs supply live context (identity, HR, risk, time, location). Policies use that context to decide allow/deny and masking; the Bouncer enforces the decision on every request.

💡 Use Cases

  • Time- and location-based access: Policies can allow or deny access by time window, time zone, or geographic location when PIPs supply that data. Example: allow sensitive operations only during business hours or from approved regions.
  • Risk- or approval-based access: Use risk scores or approval flags from PIPs (e.g. from a risk engine or workflow) to gate access. High-risk actions might require an extra check or be denied until approval is present.
  • Data masking or filtering by context: Policies can dictate what data is visible or sent downstream based on user role, clearance, or other context. The Bouncer can enforce masking or filtering so sensitive fields never reach the client or an external system (e.g. an LLM).
  • AI-related context: Control which data can be used in which AI flow—e.g. by user, session, or data classification. Combine with AI Access Controls so RAG, agents, or enterprise AI apps only receive data that policy allows for that context.

📌 Prospect Tie-Ins

  • Organizations deploying AI RAG: Use real-time permissions driven by context (e.g. user role, document classification) so RAG retrieval and model input stay within policy. PIPs supply the context; policies and the Bouncer enforce it.
  • Financial institutions or enterprises worried about data leakage: Use context (user, tenant, sensitivity) to mask or filter data before it reaches external systems or LLMs. Policies and PIPs define what is allowed; the Bouncer applies the rules at the edge.
  • Large and medium enterprises protecting sensitive data from LLMs or isolating data per user/session: Dynamic context (user, role, session) drives which data can be sent to which model or shared across users. Policies centralize the rules; enforcement and audit are consistent across APIs and AI traffic.

📌 Next Steps