Linx Blog

For the past two years, I've been building agents that expose data residing in different databases. Here, I'd like to share some actionable insights I've gathered along the way.

At Linx, we had to handle extremely high-scale databases for large enterprises. Building agents that perform well with low latency and high accuracy is hard, and the list of challenges is long.

Which model should you use? Should you fine-tune? How do you consume historical query data, and should you perform active learning? What about orchestration, do you go with an agentic framework or keep it vanilla? How do you respond quickly to investigations running against high-scale databases? And how do you rationalize cross-domain information spanning Business, Security, Governance, and Compliance?

These are just a few of the questions we had to answer.

While all of these topics are important, I'd like to focus on a different angle, one that turned out to be even more crucial.

When building an agent, engineers tend to equip it with tools that allow it to query the data, expose the schema, and assume that the agent will perform well from there. However, that's not the case.

Imagine you're exposing a schema to a junior analyst who's proficient in your database query language. Will they be able to answer questions about the data correctly? In reality, no. In the following sections, I'll explain why not, and how we solved it.

What Differentiates AI from Humans?

Jeremiah Lowin, in his excellent talk, presents criteria for how LLMs differ from humans when consuming data from APIs. Here's my version for the database problem, which is slightly different:

Real-Life Examples of Non-AI-Friendly Cases

Bad Naming: We had a field called is_external, which actually means “is the email domain external to the organization.” It does not mean the user is external, it's a property of the email itself. That naming alone caused repeated mistakes when the AI was asked about external users. The AI assumed the user was a guest, leading to incorrect security audit reports.

Different Lingo: We use a graph database. The relationship between a user and their accounts was represented by an edge named owner_of. But the relationship between a user and their secrets was named responsible_for. When someone asks "Who owns this secret?", the agent tries to generate a query using owner_of, even though we explicitly mentioned what types of edges exist and how they operate. As a result, the query returned no results, even though the data existed.

Design for Performance: We have an accounts collection, where each account represents a human in a specific application. We chose to keep the application name and data in another collection, storing only the app ID in the account document so that one could join them to get the app name if required. This was done to support the use case of app renaming without migrating many documents. In reality, since 98% of queries from accounts required the app name, this caused a huge waste of tokens as the same join query was generated over and over again. (We also found it to be non-performant for the non-agent use case as well.)

Fields That Shouldn't Be Exposed: We had many internal and legacy fields for feature flags, processing states, migration leftovers, and version counters. Things like read_for_processing and migrated—humans learn to ignore them. In some cases, the agent treats them as meaningful and starts weaving them into answers; in others, we're just wasting tokens.

Why Database Schemas Are Built This Way

Your database dialect is set by how your company talks and names things, but customer language doesn't always match your schema's language. The moment users ask questions their way, the gap shows up immediately. While engineering teams optimize for performance, storage, and clean abstractions—all valid priorities—AI agents need something entirely different: clarity and self-explanatory semantics. This disconnect persisted because, until recently, these systems were not customer-facing, and engineers who had to query the data saw no reason to complain.

Why Building a View Is Not Enough

In the MCP presentation, the suggestion is to curate a new API to be consumed by an agent alongside the existing API. One might say, "Let's build a view on top of the existing database and enforce these concepts there." However, I don't think this approach works here, for several reasons:

Views drift. New fields get added to the real model, someone forgets to update the view, and suddenly the CoPilot can't answer questions about new features. For customers, if the product and the AI's "understanding" (the view) diverge by even 5%, the Agent becomes unreliable.

Views might require duplicating the data, which is costly (depending on the type of view).

The concepts here aren't only good for an agent, but for anyone trying to access the database. The same mistakes made by an agent are also made by engineers who build queries and assume they correctly understand the schema.

This doesn't mean we can't create new fields to be consumed solely by the AI, or that there won't be fields the AI should ignore. But the majority of data should be streamlined with a process designed to ensure it is AI-Native. There's nothing more frustrating than finding out a day after a new feature was released that it's not exposed by the CoPilot.

Why Can't We Use a DAL (Data Abstraction Layer)?

A Data Abstraction Layer (DAL) is a software layer that sits between the application and the database, providing a simplified interface that hides the complexity of data storage and retrieval.

A DAL addresses many of the issues raised above. It focuses on outcomes, inner joins are already set, fields that should be ignored are removed, and it's usually explainable and optimized for performance.

However, using a query language is almost like writing code. You can do much more, and DALs are always limited by how they were designed and built. With open-ended queries, the possibilities are as broad as the database creator allows—which is usually what customers expect when asking a CoPilot about their data.

DALs are rigid; AI needs the flexibility of SQL but the safety of a DAL.

How We Solved These Challenges at Linx

At Linx, we weren't just dealing with flat tables; we were managing a massive Identity Graph. This added a layer of complexity where "truth" isn't found in a single row, but in the relationships between disparate domains—merging Business, Security, Governance, and Compliance data into a single coherent view.

We decided to build multiple tools to help our CoPilot answer customer questions. On the database side, we expose everything by default—new fields require a description and should be immediately discoverable by the agent. Alongside this, we also expose built-in APIs to save time for simple cases.

We have different mechanisms for reducing end-to-end latency around RAG and active learning, but I won't go into them in this post, as they target a different angle of how to improve CoPilot performance and reliability and would require another blog.

Engineers can decide to hide fields from the CoPilot explicitly.

The AI-Native Data Lifecycle: From Code to Production

*Yes I used Gemini to make this ridiculous diagram, it seemed only fitting given the topic. And it gets the job done!

1. Intentional Design: The journey begins with a cultural shift in how our engineers view data. During the initial design phase, engineers must explicitly classify every new field as either exposable or restricted. This ensures that data exposure is never a side effect, but always a conscious decision.

2. Static Enforcement: We utilize static analyzers to enforce our documentation standards: if a field is marked for exposure but lacks a clear description, the build is blocked. This rigid enforcement prevents "schema drift," ensuring that no new data points are silently added or forgotten without a clear contract.

3. Agentic Semantic Validation: We have developed a custom internal agent specifically designed to validate our data integrity. Rather than relying on basic syntax checks, this agent performs deep semantic analysis:

Consistency Checks: Validates that field names align perfectly with their descriptions.

Logic Verification: Analyzes calculated fields to ensure the underlying logic matches what the name implies to an LLM.

Confusion Matrix: Proactively flags near-duplicate fields or ambiguous naming conventions that could cause "hallucinations" or mix-ups during inference.

4. Production Monitoring: Finally, we maintain standard production monitoring to identify and resolve any edge-case issues or anomalies in real time.

Many Databases, Many Truths

Okay, so far so good, right? I wish it were that easy.

As I continued building, I found that this gets harder as systems mature. Real products don't query a single database. You have an operational DB, an analytics store, a warehouse, a lakehouse, documentation, and now APIs via MCP. The same concept ends up in multiple places with slightly different names or shapes. The model has to guess whether account, tenant, and org are the same thing or three different ones. We check for that too: the same entity exposed under different names across different sources, creating ambiguity.

Principles for AI-Native Infrastructure

To sum it up, when building CoPilots that run Text2SQL tasks, we should follow principles that make the CoPilot more reliable (alongside the well-known database metrics we follow, such as performance). Just as we follow SOLID principles when writing code, below is a suggested modified SOLID (or SDDID) for AI-Native infrastructure:

Semantic Naming: Table and field names must be self-explanatory. If is_external refers to an email domain and not a user's status, it must be renamed or aliased for the AI.

Dialect Alignment: The schema should match the mental model of the user. If your customers ask about "Ownership," don't hide that relationship behind technical jargon like responsible_for. Your database dialect must speak the same language as your business.

Documentation: Every exposable field must have a description attribute. This metadata shouldn't live in a separate Wiki; it should be part of the database contract.

Intentional Exposure: Not all data is for AI. Use "AI-Exposability" flags to hide internal flags, version counters, and migration leftovers that confuse the model and waste tokens.

Drift Detection: Implement automated "Semantic Tests" in your CI/CD. If a new field is added without a description or violates naming conventions, the build fails. AI-readiness is a first-class citizen.

Explicit Sharing, Implicit Availability, and Administrative Impersonation

Automation platforms rely on credentials to execute actions under a user’s identity. In n8n, credentials are created by individual users and are commonly perceived as personal, especially when they live in a user’s personal project and aren’t explicitly shared.

In a multi-user n8n instance, though, “who created the credential” and “who can use the credential” are not always the same thing. Credential availability is governed by several mechanisms. Some are explicit and intentional. Others are implicit and easier to miss. The difference matters because it directly impacts identity use, accountability, and auditability.

The observations described here are based on direct experimentation in the n8n Cloud environment.

Credential sharing models in n8n

n8n provides multiple ways in which credentials can be used by users other than their creator. These mechanisms differ in consent, visibility, and scope.

Explicit credential sharing

A credential owner can explicitly share credentials:

• With specific users
• With specific projects

Once shared, other users can execute workflows using those credentials.

This model is straightforward: the owner makes an intentional sharing decision, and other users gain access within the boundaries of what was shared.

Implicit credential availability

In addition to explicit sharing, credentials may be usable by others through implicit relationships.

Implicit case 1: Project-wide credential usage

If user A (member or admin) creates credentials in a project, other members of that project can execute workflows using those credentials, acting on behalf of user A.

This applies even if the credentials were not explicitly shared with each individual member.

In this case, credential usage remains scoped to the project, but the key detail is that “created in the project” can function like “available to the project,” even when individual user-to-user sharing never happened.

Implicit case 2: Instance admin usage across personal projects

A user can create credentials in their personal project and avoid sharing them with any other user or project.

Despite this, an instance admin can:

• Create a workflow in the admin’s personal project
• Select the user’s personal, unshared credentials
• Execute workflows using those credentials

This does not require:

• Credential sharing
• Shared project membership
• Notification to the credential owner
• Additional consent

In other words, credentials created in personal projects are still usable at the instance level by administrators. Practically, “personal” describes where the credential is stored, not who ultimately controls its use.

OAuth example: Slack credential reuse

OAuth-based integrations make this behavior especially observable because consent is usually visible to the user.

Here’s the sequence:

1. A user authorizes n8n to access Slack via OAuth
   • Tokens are issued under the user’s identity
   • Credentials are stored in the user’s personal project
2. The user executes workflows using those credentials
3. An instance admin creates a workflow in the admin’s personal project
   • The admin selects the user’s Slack credentials
   • No OAuth re-consent occurs
   • The user is not notified
4. The workflow executes
   • Actions occur under the user’s identity

Jack, a member of the organization, creates Slack credentials scoped to his personal project.

Jack does not share his credentials with anyone:

Jack approves the scopes:

Later on, the instance admin’s own credential set is visible and does not include credentials for Slack.

When the admin creates a new workflow in the admin’s personal project and adds a Slack node, the list of available credentials includes credentials created by other users. Among them are credentials created by Jack, a member of the organization, which were created in Jack’s personal project and not explicitly shared.

The admin can select Jack’s credentials and execute the workflow.

When the workflow is run by the admin, using Jack’s credentials, the resulting data corresponds to Jack’s Slack context. In an experiment we conducted, this allowed the admin to access sensitive information from Jack’s Slack channels, including messages containing salary-related information.

From Slack’s perspective, there is no distinction between actions initiated by the user and actions initiated by an admin using the user’s credentials.

What we validated in practice

In our test, an instance administrator was able to create a separate workflow and run it using another user’s Slack OAuth credentials that were stored in that user’s personal project and not explicitly shared. The workflow executed successfully without re-consent and without alerting the credential owner.

This is the core point: an admin can operationally “become” the user inside downstream systems, because downstream systems only see “valid token for user X,” not “who clicked run in n8n.”

n8n documentation and credential control

n8n states in its public GitHub repository:

“Instance owners and instance admins can view and share all credentials on an instance.”

That statement accurately describes administrative visibility and sharing capabilities.

What it does not explicitly state is that instance admins can execute workflows using credentials created by other users, including credentials stored in personal projects and not shared.

“View and share” and “run as the user” are materially different operations. The former suggests administrative oversight. The latter enables administrative impersonation in downstream systems.

Implications

This model introduces several effects that are easy to underestimate:

• Actions are attributed to the credential owner. Downstream logs reflect the user whose token is used.
• Credential owners cannot distinguish their actions from those performed by admins using their credentials.
• OAuth consent granted by a user applies beyond that user’s control. The token’s effective authority can be exercised by others.
• Credential boundaries align with instance authority rather than user intent. “I didn’t share it” is not the same as “nobody else can use it.”

These effects result from the credential availability model, not from a vulnerability or misconfiguration.

Trust model

n8n’s design assumes that instance administrators are trusted to operate using any credentials present in the instance.

In some environments, that assumption is acceptable. In others, especially those with shared administration, separation of duties, strict audit requirements, or regulated workflows, it may not match organizational expectations.

If your internal model is “admins manage the platform but cannot act as end users,” n8n’s behavior conflicts with that model.

Why this matters for agentic governance

Agentic governance has become an increasingly important issue. Automation tools are increasingly used as execution layers: they connect systems, move data, and take actions with delegated authority. Whether you call them “automations,” “workflows,” or “agents,” the governance question is the same:

Who can cause actions to occur under a given identity, and can you prove who did what?

In this model, credential ownership (who created the credential) can diverge from credential control (who can actually use it). That gap is where audit and accountability get blurry.

Takeaway

In n8n, credentials can be made available through:

• Explicit sharing by the credential owner
• Implicit availability within a project
• Implicit availability to instance administrators across personal projects

While n8n documents that admins can view and share credentials, it does not explicitly document that admins can execute workflows using unshared personal credentials and act under another user’s identity.

Organizations operating n8n should treat credential storage and OAuth authorization as instance-level trust decisions, and communicate that clearly to users.

This paper describes behavior, not intent. It clarifies where credential control actually resides.

Agentic governance with Linx

Most IAM teams already have a set of routines that work: access reviews, ownership assignment, least privilege, and remediation. Linx incorporates agentic identities into the same platform you use to secure and govern human and non-human identities across SaaS, cloud, and on-prem applications. That keeps visibility and governance consistent, even as identity types expand. 

Read more about it here: Agentic identity discovery and governance with Linx

Old identity assumptions no longer hold

Most IAM programs were built around a clean divide:

• Humans authenticate, receive entitlements, and operate within organizational norms and limits.
• Non-human identities execute narrowly defined workloads with permissions scoped in advance.

Agentic identities fit neither category because they:

• Are persistent decision-makers
• Plan, adapt, and act across multiple steps
• Decide what to do next, which systems to touch, and which tools to use based on goals and context
• Act without waiting for explicit instructions at each turn

That changes what “identity” looks like in practice. Identity does not show up as a single event. It unfolds as behavior, delegation, and a chain of access decisions that change while the agent operates.

Why this breaks traditional IAM

Traditional IAM secures moments in time, such as logins, role assignments, and token issuance. That works when access attempts are made by humans at human speed, or are machine-driven and tightly scoped.

Agents operate between those moments. They decompose goals into steps and discover and request access as they go. One permission unlocks the next. Each request can look reasonable alone, but risk lives in the sequence.

And the security problem often begins after access is granted. With long-running agents, credentials rotate, but intent persists.

What agentic identities are, and what they’re not

Agentic AI systems may comprise a single agent or multiple agents operating in coordination to achieve an outcome. These agents determine paths, tools, and systems to use, and then act on those decisions without continuous human oversight.

That autonomy changes how identity behaves. Unlike traditional NHIs, agentic identities change as agents reason, adapt, and interact with different parts of the enterprise environment.

Agentic identities are

• Goal-driven decision loops that keep operating until an objective is met
• Cross-system actors that express identity through actions, not just a single credential
• Delegation-heavy workflows that often operate through chains of service accounts, roles, tokens, and tools

Agentic identities are not

• Just “smarter bots” running a fixed script
• A single service account or workload identity you can understand in isolation
• Automatically low-risk because credentials are short-lived

How agents consume access in practice

Agents don’t approach a goal by requesting every permission upfront. They break the goal into steps. Each step reveals which tools, permissions, or data they need next, so access is discovered rather than predefined.

Traditional models grant access first and assume that usage comes later. Agents often reverse that flow. They attempt an action, learn what’s missing, and acquire the next layer of access.

Micro-example (how compounding happens):

• Agent starts with read-only analytics access
• It hits a limit and requests config-read access to diagnose the issue
• It determines a change is needed and requests write access in one system
• It delegates the fix to a deployment identity that has broader privileges

Each step can look reasonable alone. The chain is the risk.

Tool connections can create implicit privilege

Many agents do not authenticate to tools using OAuth tied to the current user. Instead, they use long-lived secrets, API keys, tokens, or service credentials configured in the workflow or agent environment.

This can create a mismatch between who is allowed to run the agent and what the agent can do. A user may have limited direct access to an application, but by running an agent that already has a permanent credential configured, they can trigger actions they should not be able to perform.

From the outside, it still looks like normal tool usage. The risk is that the permissions are effectively inherited through configuration, not granted through an approval process tied to the user and the moment.

Why short-lived credentials don’t eliminate identity risk

Short-lived credentials reduce exposure, but they don’t remove accountability gaps.

Agents rely on temporary tokens, delegated credentials, and role sessions. Tokens expire and sessions rotate, but an agent’s intent persists. As one credential ends, another replaces it.

IAM records separate events tied to different identities, but in reality, it is one actor continuing the same reasoning. The question becomes how access combines across identities to reach an outcome. Without that connection, accountability breaks and intent is invisible.

Delegation chains are where context disappears

Delegation is how agents operate at scale, and it’s where visibility erodes fastest.

Agents work through chains of delegation: impersonating service accounts, exchanging API tokens, and federating into workload identities. Each handoff can be valid. Each hop can behave as designed.

The problem is context loss. Most IAM systems record these as separate events. A role assumption here. A token exchange there. What they miss is the sequence that connects them. Without that thread, identity becomes fragmented execution instead of a single decision-maker spanning systems.

Security teams then reconstruct behavior after the fact, inferring intent from logs never meant to explain it.

What this looks like in a real enterprise

Agent permissions in the enterprise can look ordinary until viewed collectively.

Scenario 1: “Fix the performance issue”

An agent detects a performance issue with limited analytics access, assumes a diagnostic role, identifies a configuration problem, and fixes it using a separate deployment identity.
IAM logs each step under a unique identity. None appears risky alone. The real identity is the agent coordinating the entire sequence.

Scenario 2: “Prepare a report”

An agent is asked to prepare a quarterly report. It pulls metrics from a BI tool, then discovers it needs customer fields from a CRM. A developer previously connected the CRM using a long-lived API secret so the agent can “just work.” The agent exports the dataset to a collaboration tool to share with stakeholders.
Each system sees a legitimate action. The risk is the combined outcome: sensitive data moved across systems using credentials that are not tied to the user running the agent, through a chain no single control point evaluated end-to-end.

This is why agentic identities are easy to underestimate. Their behavior only makes sense in the context of a continuous decision loop.

Start here this week

If you do nothing else, start by making agentic identity visible and governable in the places where risk concentrates.

Start here checklist:

• Inventory where agents already operate (workflows, platforms, SaaS copilots, internal tools)
• Identify which identities they execute through (service accounts, roles, tokens, workload identities)
• Inventory agent tool connections and how they authenticate (OAuth vs long-lived secrets)
• Identify run-context mismatches (who can run an agent vs what its configured credentials allow it to do)
• Flag high-impact actions (IAM changes, data exports, production deploys, privilege grants)
• Define guardrails for those actions (allowed tools, allowed targets, approval requirements)
• Require traceability through delegation chains (correlate hops back to the originating agent or workflow)

This is foundational. You cannot govern what you cannot map.

How risk scales in agentic environments

Agentic identities accumulate risk faster because access is discovered, chained, and delegated across systems and identities.

Compounding access creates sideways expansion

Privilege expansion becomes autonomous when agents optimize for task completion unless guardrails restrict decision scope.

This can begin with narrow permissions. As the task develops, those permissions unlock the need for additional access. The expansion is not always a single obvious escalation. It can be accumulation across tools and identities.

Least privilege cannot be treated as a one-time entitlement decision. For agents, it has to be enforced continuously for high-impact actions, and evaluated in the context of the decision loop.

Coordination multiplies visibility gaps

Multi-agent coordination multiplies risk because identity context fractures as tasks are delegated across many agents.

Agents collaborate to complete complex workflows. One analyzes data, another diagnoses infrastructure, and a third applies changes. Each may operate under different identities, tools, or domains.

Everything can look normal to individual systems. What disappears is the thread connecting actions into one decision flow. Fragmented visibility lets risk spread even when no single agent appears over-privileged.

Misuse scenarios that matter

New scenarios show up when influence becomes as important as direct access:

• An agent nudges another agent to execute a privileged action, and each individual step appears legitimate.
• An agent splits actions across systems so no single log stream looks suspicious, but the combined outcome is harmful.

These are identity problems because they depend on delegation paths, chains of authorization, and missing end-to-end context.

Why audits and investigations struggle

Audits struggle because execution is easier to record than reasoning.

Logs capture events. They rarely capture why decisions were made or how actions connect across systems. Traditional IAM trails flatten behavior into isolated entries, forcing teams to infer intent after the fact.

In practice, the hardest investigations involve tool connections. If an agent used a stored secret, the audit trail often shows the tool identity, not the human who triggered the run, and not the full chain of connected systems. This is why correlation across the full flow matters, not just collecting more logs.

In an agentic world, accountability depends on connecting:

• the originating objective
• the chain of identities used
• the sequence of actions
• the final outcome

Without that, you can have “complete” logs and still have incomplete answers.

How to explain agentic identity internally

Agentic identity is hard to govern if teams can’t describe it consistently.

One-minute explanation for executives

Agents behave like autonomous digital workers. They can be fast and independent, but risk comes from decision speed multiplied by visibility gaps. IAM must connect intent and execution so you can understand what the agent was trying to do, what identities it used, and what it changed.

Explanation for architects and engineers

Agentic identity works in a loop:

• An agent forms intent
• It discovers missing access
• It executes through an identity (often an NHI)
• It produces an outcome
• The loop repeats until the objective is met

Governance has to follow that loop. Visibility, boundaries, and traceability need to apply across steps, not just at login.

Misconceptions to stop repeating

• Short-lived credentials don’t automatically mean low risk when intent persists.
• Agents aren’t just smarter bots. They’re decision-makers operating across systems.
• When behavior drives access, risk shows up in the chain, not a single event.
• Agents are not just NHIs.

What this means for your IAM program

The rise of agentic identity necessitates a new approach.

• Treat decision sequences as first-class security objects, not just entitlements.
• Correlate actions across tokens, roles, and NHIs back to the originating agent or workflow.
• Define guardrails for what decisions agents can make as context changes, especially for high-impact actions.

This allows autonomy and delegation to be treated as identity behaviors that require supervision and traceability.

Conclusion

Agentic identities change the shape of identity risk. The biggest shift is not that agents authenticate differently. It is that they operate continuously, discover access as they go, and act through delegation chains that fragment context.

If IAM continues to govern only logins, roles, and tokens in isolation, it will miss the behavior that matters. The path to control starts with visibility into where agents run, what identities they use, and how multi-step decisions connect to outcomes.

Agent discovery with Linx: visibility with context

Linx provides Agentic Identity Governance and Discovery to close that gap, and give teams a single platform to security and govern human, non-human, and agentic identities.

Along with your human and non-human identities, an AI access control tool like Linx allows you to discover which agents are in use, who has access to them (humans or other agents), and what those agents have access to.

Who is allowed to run an agent vs what the agent can reach

Agents often carry permanent access through long-lived secrets and pre-wired tool connections. Linx helps you see mismatches between who can execute or influence an agent and what the agent’s configured credentials allow it to do. This makes implicit privilege visible so teams can remediate it.

Agent to app flow mapping across connected tools

Developers connect agents to many apps quickly, often through generic HTTP and API components or custom connectors. Linx correlates agent activity into an end-to-end flow from agent to application to resource. This helps teams understand blast radius, spot unexpected connections, and investigate multi-step behavior without stitching evidence together manually.

Which agents exist and who owns them?

Get an inventory of agents and quickly flag ones without clear owners.

Who can access the agent?

You can see which accounts have access to an agent, which helps you understand who can run it, manage it, or influence its behavior.

What does the agent have access to?

You can review the permissions and resources the agent can reach, including signals that help you prioritize what to look at first, and how the agent got the access in the first place (API token, service account, OAuth, etc.).

Bring agentic identities into your existing governance program

Most IAM teams already have a set of routines that work: access reviews, ownership assignment, least privilege, and remediation. Being an agentic identity governance and AI access control platform, Linx incorporates agentic identities into the same platform you use to secure and govern human and non-human identities across SaaS, cloud, and on-prem applications. That keeps visibility and governance consistent, even as identity types expand.

A new type of identity

AI agents are becoming part of day-to-day work. Teams use them to automate workflows, write and run code, move data between systems, and perform tasks that previously required a person to click through multiple tools.

Like most new technologies, the first challenges from a security and governance perspective are visibility and understanding. If you can’t see which agents exist, who owns them, who can use them, and what access they have, you can’t make informed decisions about risk. 

Linx provides Agentic Identity Discovery and Governance to close that gap, and give teams a single platform to security and govern human, non-human, and agentic identities. 

Agent discovery with Linx: visibility with context

Along with your human and non-human identities, you can discover which agents are in use, who has access to them (humans or other agents), and what those agents have access to. 

Which agents exist and who owns them?
Get an inventory of agents and quickly flag ones without clear owners.

Who can access the agent?
You can see which accounts have access to an agent, which helps you understand who can run it, manage it, or influence its behavior.

What does the agent have access to?
You can review the permissions and resources the agent can reach, including signals that help you prioritize what to look at first.

Bring agentic identities into your existing governance program

Most IAM teams already have a set of routines that work: access reviews, ownership assignment, least privilege, and remediation. Linx is human, non-human, and agentic AI security solution that secures all identity types in one platform across SaaS, cloud, and on-prem applications. That keeps visibility and governance consistent, even as identity types expand.

Get started

If you’re already using Linx, start by opening the “agents” tab under “discovery”. If you want to see Agentic Identity Governance and Discovery in action, reach out to your Linx team for a walkthrough and best-practice guidance on how to operationalize it in your environment.

TL;DR

Any identity-related question you ask once, might be worth asking again. What contractors have admin access to company apps? How many AI agents are currently in use? How many partially offboarded users do we have? AI-scheduled reports let you turn any question into a recurring report that runs on your schedule.

The Linx AI Agent

The Linx AI Agent sits on top of your connected identity graph (users, non-human identities, entitlements, resources, and the relationships between them) and uses reasoning to help you find insights and take action. You use it by asking plain-English questions (for example, who has admin access in a given system, or where risky access is coming from), and it returns answers plus context-based recommendations for common workflows like access requests, user access reviews, access profiles, and custom reporting. Where you’ve granted permission, it can also trigger the next step, like kicking off remediation options or executing an approved action, so investigations and cleanups don’t die in tickets and spreadsheets.

AI-scheduled reports

Using the Linx AI agent, you can turn any question into a recurring scheduled report.  For example, one customer recognized a pattern of questions he always gets on a weekly meeting, so he automated the answers for those into reports that land in his inbox every week before the meeting. 

To set up a scheduled report, start by asking a question:

You can keep investigating until you get the data you want, once you do, tell the agent to turn it into a scheduled report:

And that’s it! You’re also able to configure the report to add additional recipients, change the frequency, or manually run the report now. Once you set it up, the report will show up on the configured inboxes on the schedule you set:

Example use cases

Any question that can be answered with data neatly arranged in a table can be turned into a report. Here are some of the most common questions we see our customers use:

1. “List dormant admin accounts” - The AI Agent will find accounts with elevated privileges that haven't been used recently, as these could potentially present a security risk. Customers often run a recurring check for these accounts.
2. “Detect partially offboarded users” - A partially offboarded user is someone whose lifecycle status indicates they should be fully deactivated, but they still have active accounts in some applications. This represents an incomplete offboarding process and poses a security risk. Large companies tend to have more churn, so identity teams regularly run this check to reduce their attack surface as part of their identity lifecycle management process.
3. “List all orphaned accounts” - This reveals accounts that exist in your applications but have no corresponding identity in your authoritative identity sources (HR systems or Identity Providers like Okta/Azure AD). These "orphaned" accounts often result from incomplete offboarding processes, manual account creation, or integration gaps. Orphaned accounts are a significant security risk because they exist outside your normal identity governance processes and are unmonitored, unmanaged, and often forgotten.
4. “List all AI agents with their permissions and resource access” - With AI agents on the rise, we’re seeing identity teams prioritizing visibility and governance over them. This report provides a complete inventory of all AI agents in your environment, showing their names, associated applications, tools and permissions they have access to. As AI agents are autonomous software entities that can interact with critical systems and data, they represent a growing security and governance challenge. 

Get Started

Linx customers typically get valuable insights on day one. To learn more about how Linx can work for you, book a demo with one of our specialists. 

How Forrester defines the new workforce identity stack

Forrester defines workforce identity security platforms as unified platforms that govern, administer, and enforce identity security safeguards across workforce users, human and nonhuman, to protect networks, applications, and data. These platforms pull together identity data sources, SSO, MFA, access management, and identity governance, then layer on AI-driven identity intelligence and analytics.

In other words, this is no longer “just IAM.” The platform is expected to:

• Deliver identity-centric security and help prevent identity-based attacks by eliminating security gaps and reducing the attack surface.
• Maintain regulatory compliance and audit readiness across frameworks like SOX, GDPR, PCI DSS, and DORA.
• Improve workforce productivity with streamlined onboarding, access requests, SSO, and self-service.

Forrester also calls out the growing pressure from nonhuman identities and AI:

• The proliferation of nonhuman identities (NHIs) like service accounts, workloads, APIs, and AI agents is now a primary challenge that drives identity sprawl and business risk.
• The agentic AI workforce is named as the top disruptor, requiring new governance, lifecycle, and risk detection models, along with support for emerging AI security protocols and standards.

This is exactly the world Linx was built for: a mix of humans, machines, and AI agents that all need access, all the time.

Where Linx shows up in the Forrester Landscape

The report covers 32 vendors globally. Linx Security is listed among those vendors, alongside hyperscalers, long-time IAM players, and a small number of specialized identity security platforms.

Forrester then breaks the market into:

• Core use cases: identity and access policy administration, workforce onboarding and offboarding, secure workforce access, and regulatory compliance reporting.
• Extended use cases: IAM process automation, identity governance, identity security posture management, identity threat detection and response, machine and AI agent identity management, and third-party access management.

In the extended use case matrix, Linx is listed in three specific areas:

1. Identity governance
2. Machine and AI agent identity management
3. Identity security posture management

Those three are not generic checkboxes for us. They are the center of how the Linx platform is designed.

Why these areas matter, and how they map to what Linx does

1. Identity governance: modern IGA that people actually use

Forrester treats identity governance as one of the extended use cases that differentiates workforce identity platforms beyond basic IAM.

In practice, that means:

• Running access reviews that do more than produce spreadsheets.
• Enforcing least privilege without creating months of manual role modeling.
• Proving to auditors, at any time, who has access to what and why.

Linx leans into modern IGA with AI-assisted access reviews, contextual recommendations, and immutable, auditor-ready reports. The goal is simple: get your certifications done faster, with higher quality decisions, and leave behind an evidence trail that stands up in front of a regulator or a board.

2. Machine and AI agent identity management: securing the agentic workforce

Forrester calls out the proliferation of nonhuman identities and the rise of agentic AI as both a primary challenge and the top disruptor in this market.

This is where Linx has been investing heavily:

• Treating AI agents, service accounts, and workloads as first-class identities, not an afterthought.
• Giving security teams visibility into what those agents can reach, and what they actually use.
• Applying the same least-privilege, lifecycle, and review controls to nonhuman identities that you already expect for human users.

As enterprises push more work into autonomous agents, this becomes a board-level risk question, not a tooling detail. Seeing Linx recognized in this emerging use case is a strong signal that we are aligned with how the category will evolve over the next few years.

3. Identity security posture management: from “who has access” to “what should we fix first”

Forrester describes how workforce identity platforms are increasingly defined by AI-driven identity security intelligence. They are expected to detect drift and misconfiguration, and support real-time identity threat detection and response.

That is essentially the identity security posture management problem:

• You need a complete map of identities, entitlements, and relationships.
• You need to know which patterns represent real risk, not just noise.
• You need a path to remediate excessive or toxic access, not just report on it.

Linx tackles this with graph-based visibility across SaaS, cloud, and business apps, layered with AI that flags excessive privileges and risky access paths. Then, instead of stopping at “observability,” we allow teams to actually remediate from within the platform, with automation where appropriate and human review where needed.

What this means for customers

This Forrester Landscape is not a ranking or a Wave. It is a map of who is in the game and how the market is shifting. Being included is step one. Being listed in extended use cases that sit at the heart of the next identity decade is the more important part.

For our customers and partners, the message is straightforward:

• You are not alone in feeling that traditional IAM and legacy IGA were not designed for today’s mix of humans, machines, and AI agents.
• Analysts now describe the market in terms that match the problems you are bringing to us every week: posture management, governance that works at scale, and control over nonhuman identities.
• Linx is recognized as one of the vendors focused on exactly those problems, not as a generalist tool trying to be everything to everyone.

We will keep sharing more detail on how we approach identity governance, posture, and AI agent control over the coming months. For now, this report is a useful validation that the hard problems you are asking us to solve are the same ones reshaping the entire workforce identity security market.

Find the full report here: Forrester Workforce Identity Security Platforms Landscape.

Most organizations still deal with a lot of standing access. A user gets elevated access and we forget to revoke it, or someone switches roles and keeps their access from the old one. Our attack surface grows with each standing permission. Just-in-time access flips that default. You grant only what is needed, exactly when it is needed, and you remove it as soon as the work ends.

In this article I hope to give identity and security teams a practical path to make JIT access the standard operating model. We define JIT, show how it fits with RBAC and ABAC, explain where it works best, explore how agents change the picture, and outline how to build, roll out, and measure a program that improves both productivity and security.

What is JIT (Just-In-Time)?

Just-in-time access issues time-bound and scope-bound permissions on demand, then revokes them automatically. Think of it as least privilege with a clock and a clear scope. Unlike a standard access request, expiry is part of the grant. No one needs to remember to remove anything later.

JIT began as an emergency scenario, like when an admin needs elevated access quickly to resolve an urgent issue. Modern identity platforms and cloud controls now support it across a much wider set of tasks. JIT can be the default for any permission you do not use daily, including sensitive SaaS roles, database privileges, cloud consoles, CI pipelines, and internal admin functions.

How JIT Works With RBAC and ABAC

Role Based Access Control assigns access based on membership in a role. You define a role once and map it to entitlements. For example, everyone with the Marketing role gets HubSpot and Canva.

Attribute Based Access Control grants access when a policy evaluates to true across attributes of the user, resource, action, and environment. The policy defines who qualifies, not a static group. For example, grant HubSpot and Canva to users whose role is Marketing, employment type is FTE, location is US, and manager is John Smith.

Just in time adds duration and task. Keep the baseline role small. Use ABAC to narrow eligibility and conditions. When a task requires elevation, issue a short-lived entitlement tied to a specific action and resource. ABAC decides who qualifies under current conditions, and JIT limits how long and how broadly the grant applies. You can also use ABAC to block requests outright if the requester does not meet basic requirements like MFA or compliant device.

When is it Time for Just-In-Time?

JIT fits two patterns. The first is routine elevation on a predictable cadence. Consider quarter-close finance tasks, maintenance windows, or periodic schema changes. The second is ad hoc work where someone needs temporary rights to unblock an incident or enable a deployment.

Ownership matters in both cases. Requestors should not need to be security experts. Application and entitlement owners define what can be JIT-granted, under which conditions, and for how long. Security teams codify guardrails and step in for high-risk changes or separation of duties checks. Approvals start with the owner who understands the operation, with security engaged when risk or policy requires it.

A simple example illustrates the idea. A product manager occasionally needs admin rights in a support tool to add a contractor. Today that person might keep admin forever because it is convenient. With JIT, they request a task-scoped admin profile that expires in X minutes. The system records who, what, why, and for how long access was granted. The job gets done, and the background risk stays low.

Agents And Non-Human Identities

AI agents are now autonomous actors inside the enterprise. They make decisions, access systems, and execute tasks with little human oversight. That makes them identities in their own right, not just wrappers around service accounts or API keys. Treat them as first-class identities with owners, clear purposes, and explicit scopes.

Most teams cannot answer three basic questions today. Which agents are running in our environment. What systems can they access? What permissions do they actually hold? This visibility gap is the core risk as adoption accelerates.

Agents behave differently from traditional NHIs. A service account follows fixed logic. An agent interprets context, adapts, and tries alternate paths until it completes the task. It operates at high speed and at scale. If it inherits broad standing rights, the blast radius grows quickly.

The model that works looks a lot like how you govern people, with tighter controls and shorter windows. Start with an agent registry. Record owner, purpose, allowed tasks, baseline scopes, and last activity. Link each agent to the machine credentials it may use and to the data it can touch. Represent these relationships in your identity graph so every request is evaluated in context.

Just-in-time access is essential for agents. Give the agent only the permission it needs for the specific task and for a short period. Do not let it reuse a human sponsor’s standing rights. When the timer expires, revoke tokens, sessions, and keys.

Round out the guardrails with a small set of practices that scale:

• Identity profiles that define purpose, baseline permissions, and ownership
• Human-in-the-loop approval for any elevation beyond the baseline
• Continuous monitoring for unused rights, anomalous behavior, or scope creep
• Automated identity risk remediation that revokes excess, suspends risky agents, and notifies owners

This approach keeps autonomy without losing control. You gain clear accountability, smaller blast radius, and audit-ready records for every decision. Most important, you align agent productivity with least privilege by default, not as an afterthought.

A JIT Architecture That Scales

JIT thrives when four layers work together and feed one another.

1) Visibility

Start with an accurate catalog of identities, entitlements, applications, resources, and owners. Include people, service accounts, workload identities, and agents. Map who can grant what. Assign ownership for every entitlement and admin function. Integrate data from your IGA, directories, cloud accounts, SaaS admins, and data platforms. Without this map you cannot know what you are granting or who should approve it.

2) Policy And Decision

Define who can request what, under which conditions, and for how long. Use ABAC to enforce basic security requirements. Link higher risk actions to change records. Tier approvals by risk (what gets auto-approved vs. what needs human review). 

3) Intelligence

Add context to each request. Does the request align with the requester's job title and team? Do other team members have this access? Does the user have a history of violations? Present recommendations that reduce cognitive load for approvers. The goal is not to replace judgment. It is to give the resource owner structured context so they can decide quickly and confidently.

4) Fulfillment And Audit

Provision at the smallest practical unit. Prefer ephemeral roles, short-lived tokens, and session policies rather than group adds. Revoke everything when the timer expires, including sessions and keys. Write a durable audit trail that captures requestor, approver, reason, scope, and duration. Index every grant so user access reviews become faster and more meaningful.

Rolling Out JIT

Start where the impact is highest. Choose a sensitive SaaS app and a production cloud account. Inventory admin actions, define owners, and mark which actions are JIT-eligible. Set short default durations and clear approval paths. Run a small pilot with people who understand the tasks and can provide actionable feedback.

Limit the audience at first. You can hide the JIT entry point from general users until owners and security are comfortable with the flow. As confidence grows, expand who can request JIT and add more actions and teams.

Make audit an explicit outcome. Every JIT grant should produce an easy to read record for compliance. This reduces manual effort during periodic reviews and gives auditors clear evidence of least privilege.

Guardrails For Agents

Agents need the same rigor as people, plus a few extras. Maintain a registry of agents with owner, purpose, allowed tasks, and data sensitivity. Use short-lived credentials with narrow scope. Avoid reusable keys and prefer brokered, time-bound tokens. Require human initiation for scope changes. Agents may request within their allow list but cannot extend it on their own. Build a kill switch that revokes all agent tokens at once. Connect it to anomaly detection so you can respond quickly without guesswork.

Measuring JIT Success

A focused set of metrics shows progress. Track the percent reduction in standing high-risk entitlements. Measure mean time to elevation and approval success rate. Watch median JIT session length and the share that end by auto revoke. Monitor reviewer load during access reviews and incidents linked to stale permissions.

The target state is clear. Elevation for legitimate work is fast. Background risk trends down. If both lines move in the right direction, your model is working.

Common Failure Modes And Fixes

Approval fatigue is the most common failure. Owners and security get overwhelmed by noisy requests. Reduce volume with clear task packs and strong defaults. Use recommendations so owners see a simple approve or deny with the right context.

Temporary group adds are another trap. Groups linger and create blind spots. Prefer ephemeral roles or policy attachments that expire automatically. When groups are unavoidable, require an expiry and verify revocation after the window closes.

Agent inheritance is a quiet risk. Do not let agents reuse human standing rights. Bind them to their own service principals and JIT policies.

How Linx Implements JIT

Linx treats identity as a security problem first. The platform builds a graph that unifies people, non-human identities, and agents across SaaS and cloud. Every request consults this graph in real time. Risk signals and peer comparisons help owners decide quickly. Policies blend RBAC, ABAC, task context, and separation of duties.

Provisioning is granular. The system attaches the smallest scope required for the task, issues short-lived credentials, and tears them down on expiry. The same flow works for human users, workload identities, and agents. Approvals start with the resource owner and escalate by risk, which keeps security focused on the reviews that matter most. Every action writes a complete audit trail so access reviews and certifications become faster and more accurate.

Customers tell us the difference is the security-first lens. The goal is not only faster approvals or cleaner audits. The goal is safe productivity. JIT captures that goal by cutting background risk while keeping teams moving.

Bringing It Together

Standing access is quiet exposure that grows over time. Just-in-time and just-enough access, paired with dynamic access profiles is how you ensure that exposure stays at a minimum. You grant only what is needed, when it is needed, and you remove it on time.

Most identity teams have done the responsible work. You set up an IdP for SSO, enforced MFA, rolled out IGA, and protected admin paths with PAM. Yet privilege-creep lingers, offboarding is inconsistent in the details, and blind spots show up across SaaS, cloud, on-premise, and internal systems. That outcome is not a bad strategy or a failure to follow best practices. It is the natural result of growth and complexity. People move roles, apps multiply, automation creates new access edges, and non-human identities are on the rise. Meeting that reality calls for a new way to understand and act on identity.

That is the point of an Identity Visibility and Intelligence Platform (IVIP). An IVIP is a single place that unifies identity data, models how permissions actually relate to resources, and presents decisions you can carry out in the flow of work. It does not discard what you already have. It helps you run it better. In some organizations it also starts to absorb work that once lived in a legacy IGA suite. The goal is simple - make identity management easier and safer for admins, security teams, and end users.

The challenge with today’s stack

Identity programs grew up in a world of clearly bounded systems. Today the edges are fuzzier. A single user can participate in or hold a mix of IdP groups, application roles, inherited permissions, and temporary tokens. A single workload can carry keys and service principals that unlock powerful APIs. None of these are bad on their own. The problem is that the important questions are relational. Who can do what on which resource. What breaks if we remove this group? Which rights are unused and could be reduced?

Tabular inventories struggle with relational questions. They are good at counting, not at explaining. When decisions depend on how objects connect, you need a model that treats connections as first class citizens. That’s the gap I see IVIP stepping into.

Model relationships, not rows

Identity is a network of relationships. Human to account. Account to group. Group to role. Role to permission. Permission to resource. Owner to business unit. A platform that understands these links can answer the questions that matter and can do it in near real time. That is why a graph model is the right foundation. It makes it cheap to ask hard questions and safe to automate the obvious ones.

Here is a scenario that plays out every week: A senior engineer moves into a product role. HR updates the employee record. Some IdP groups change. On the surface, access looks correct. Yet a handful of admin privileges remain through inherited groups and application-local roles. The person no longer needs elevation but still holds write or admin rights in systems that touch production. A graph reveals the full path that keeps those rights alive. An IVIP should tie the HR event to identity edges, highlight the drift, show the exact inheritance that matters, and propose a safe remediation plan. You remove the unneeded entitlements, convert any remaining elevation to just-in-time, and keep the evidence for audit. No spreadsheets. No guesswork. No surprises six months later.

Intelligence that gets work done

Dashboards summarize. Intelligence drives change. Useful identity intelligence has three traits. It is explainable, precise, and actionable.

Explainable means you can see the path that produced the score or the alert. Breadth of access matters, but so do signals like inactivity, weak factors, external ownership, or exposure to sensitive resources. If you can explain and understand the calculation, you can defend the decision.

Precise means the recommendation is specific. Remove entitlement A and group B. Usage has been zero for 90 days. Peers in the new role do not hold either. Residual rights still allow task C. That is a decision a manager or owner can approve quickly.

Actionable means you close the loop in the same place you saw the issue. Revoke or reduce with one action. Time-bound a role and move on. Route a minimal approval to the true owner with context attached. The cost of doing the right thing needs to be low. 

Coverage that matches how people and systems actually work

Coverage is not a list of connectors. It is a promise that the model reflects reality. That means human and non-human identities with clear ownership. SaaS, cloud, and on-prem applications with resource-level permissions, not just role names. Accounts inside and outside SSO, including application-local identities that bypass centralized controls. Peer and behavioral context so least privilege can be achieved with confidence. Segregation of duties checks that cross systems rather than living inside a single suite.

If one of these dimensions is missing, you introduce governance gaps or create an audit headache. An IVIP should bring them together so you can reason across them without stitching exports by hand.

What impact should an IVIP have?

Teams that adopt an IVIP, or a set of features that amount to the IVIP promise, should feel the impact in their first quarter. The first change is clarity. Dormant accounts, unused admin roles, overprivileged accounts, and other risks surface with owners attached and suggested fixes ready to go. The second change is decision quality. Right-sizing stops being personal and becomes a repeatable pattern. The platform shows the path, explains the risk, and proposes the minimal safe change. Approvals get shorter because the context is built in. The third change is operational momentum. Mean time to remediate identity risk becomes a real metric. Access becomes both safer and faster because defaults are designed to unblock work without widening blast radius.

There is also a cultural effect. Security and IT work from a single source of truth. Less time is spent reconciling spreadsheets. More time is spent making clear reductions that everyone understands.

A pragmatic way to start

Start by unifying what you already own. Ingest IdP, HRIS, IGA, PAM, the major SaaS applications, cloud providers, and the internal systems that carry the most risk. Normalize identities and connect both human and non-human principals to owners and resources. Then turn on opinionated detections. Focus on partially offboarded users, inherited admin rights, application-local accounts, orphaned service identities, risky factors, unused entitlements, and cross-system SoD. Require each finding to ship with owner, impact, and a proposed remediation.

From there, move to continuous right-sizing. Use usage data and peer baselines to convert standing privilege into least privilege. Prefer time-bound or approval-bound elevation over permanent admin. Simple policies go a long way. For example, remove any entitlement unused for a set number of days unless the owner opts out with a reason.

Close the loop with one-click actions and lightweight approvals. Record evidence automatically. Measure what matters: privileged account count, accounts outside SSO, time to remove unused admin access, percentage of time-bound elevation, and the number of automated right-sizing actions. These measures tie identity work to risk reduction and business velocity.

Use AI as an accelerator with guardrails. Summarize context, propose candidate roles, and prioritize onboarding. Keep data scoped to the task, respect privacy, and admit uncertainty rather than guessing. AI should help you move faster on correct work, not cover up missing data.

Where this leaves IGA

IGA remains useful for identity lifecycle management, certifications, and policy. IVIP complements that mission by providing full-fidelity visibility, trustworthy analytics, and closed-loop execution. In some environments IVIP will take over most decisioning and remediation while IGA handles specific compliance workflows. In others, teams choose to consolidate further. The point is not to keep every tool. The point is to meet today’s complexity with a model and workflow that can keep up.

The bottom line

You do not need to master every application’s permission model. You need a platform that understands them, unifies them, and gives you the fastest safe decision for each situation. That requires a relationship-aware model, explainable analytics, disciplined use of AI, and an operational loop that ends in a real change. Build IVIP on those principles and you will find issues sooner, fix them faster, and keep people moving without widening risk. That is what good identity looks like at modern scale.

[New York, New York], USA — [09/30/2025] — Linx today announced its inclusion in the Microsoft Security Store Partner Ecosystem. Linx was selected based on their proven experience with Microsoft Security technologies, willingness to explore and provide feedback on cutting edge functionality, and close relationship with Microsoft. 

"Microsoft is a foundational company in the identity space, and are uniquely aware of the importance of making modern identity security and governance accessible and easy to use. We’re honored to work closely with their security teams bringing that vision to life.”
Israel Duanis, CEO & Co-Founder, Linx

“The Microsoft Security Store is designed to simplify and strengthen how organizations approach cybersecurity. By offering a curated selection of trusted solutions and AI agents, we help Security and IT teams quickly find, purchase, and deploy technologies that integrate seamlessly with Microsoft Security. With simplified billing, streamlined deployment, and verified integrations, the Security Store empowers defenders to accelerate their response, improve their security posture, and focus on what matters most.”
‍Dorothy Li, Corporate Vice President, Security Copilot, Ecosystem and Marketplace

Linx is collaborating with Microsoft to help shape the development of the Microsoft Security Store, providing feedback on new features, integration experiences, and customer needs. By publishing certified solutions and AI agents that integrate seamlessly with Microsoft Security products, Linx is making it easier for organizations to discover, purchase, and deploy trusted security technologies. Through the Security Store, Linx is helping customers accelerate their security outcomes and simplify operations with solutions that are vetted, easy to deploy, and designed to work together.

The Microsoft Security Store is setting a new benchmark for cybersecurity procurement and deployment. By centralizing a wide range of security solutions and AI agents—organizations can now streamline how they discover, acquire, and operationalize advanced security technologies. With features like industry framework alignment, simplified billing, and guided deployment, the Security Store helps security teams reduce complexity, accelerate adoption, and maximize the value of their security investment

About Linx: 

Linx gives identity teams unified visibility, governance, and risk remediation across human and non-human identities, for cloud, SaaS, on-prem, and custom applications. With a graph-powered view and AI guidance, Linx users enforce least privilege, replace standing access with JIT, and turn UARs from rubber-stamping into evidence-backed decisions.