RSAC Innovation Sandbox | Token Security： Advocate of the Machine-First Identity Security Concept
Company Introduction
Token Security[1] (see Figure 1) is a cybersecurity company focusing on the security of Agentic AI and Non-Human Identities (NHI). It is committed to building an “identity layer” that enables Agentic AI to land securely.
RSAC Innovation Sandbox | Token Security： Advocate of the Machine-First Identity Security Concept
Company Introduction
Token Security[1] (see Figure 1) is a cybersecurity company focusing on the security of Agentic AI and Non-Human Identities (NHI). It is committed to building an “identity layer” that enables Agentic AI to land securely. As AI agents evolve from assistants to independent actors that can perform tasks, Token Security provides capabilities covering identity lifecycle management and intent-based access management, helping enterprises accelerate the scale of AI applications and reduce identity and permission risks while gaining complete visibility, governance and control.
Figure 1 Token Security website homepage
Token Security was founded in 2023 by two co-founders (see Figure 2), Itamar Apelblat (left) and Ido Shlomo (right):
Figure 2 Co-founder of Token Security
Itamar Apelblat is the co-founder and CEO of Token Security, with more than 15 years of technical accumulation and leadership experience in the field of cybersecurity. He served as an officer and R&D team leader in Israel’s elite unit 8200, leading several advanced cybersecurity projects [2].
Ido Shlomo is the co-founder and CTO of Token Security. With deep experience accumulated during his service in Unit 8200, Israel’s elite cyber intelligence unit, Ido Shlomo brings unique expertise in offensive and defensive fields to the forefront of enterprise security [3].
Product Background
NHI enables traditional applications and AI applications, various services and automated processes to complete authentication, secure communication and operation execution within the product and IT environment and between third parties. NHI includes service accounts, API keys, cloud roles, container workloads, CI/CD pipelines, and machine-generated credentials that help achieve secure access to systems and data (see Figure 3). As part of digital transformation, organizations continue to adopt cloud technology, automation and AI-driven infrastructure. As a result, NHI has grown exponentially and far outnumbered human identities [4] .
Figure 3 NHI in an enterprise environment
A more critical change comes from the implementation of generative AI within enterprises. AI Agents are assistants and tools on the surface, but to complete actions such as retrieving data, calling SaaS, executing work orders, and reaching production resources within an organization, they often have to use Tokens, integration accounts, or service accounts to obtain permissions. Therefore, AI Agent is more like a “hybrid identity subject”: it has certain autonomous decision-making and automatic execution capabilities, and inherits and amplifies existing permissions through programmatic credentials. Without clear identity boundaries, responsibilities and authority fences, AI Agent will not only amplify the already complex NHI risks, but also make the risks spread faster and more difficult to trace by penetrating into more business processes. It is specifically reflected in the following aspects:
(1) Identity subject expansion risk: from Human to NHI
Critical operations are increasingly completed by services, scripts, pipelines and system integration rather than direct human login.
The introduction of AI Agent has upgraded the “automated executor” from a fixed script to a more dynamic agent; but the permission carrier is still Token/service account, resulting in more blurred identity boundaries and more difficult authorization constraints.
(2) Scale and life cycle risk: quantity explosion leads to inventory failure
The number of NHIs often far exceeds that of human accounts, and contains a large number of short-lived, task-generated credentials and identities.
The creation entrance is highly scattered (development, platform, data, and business integration generate vouchers separately), registration is incomplete, updates are not timely, and inventory is quickly distorted.
(3) Risk of lack of visibility: If you can’t see it, there is no control
Many NHI/Agents do not appear in the traditional IAM inventory in full, and clues are scattered in key libraries, code repositories, CI/CD configurations, cloud and SaaS audit logs, runtime telemetry, and third-party/AI provider call records.
The result is that organizations have difficulty answering the most basic questions: which tokens/agents are being used, where, and what resources are being accessed.
(4) Risk of context and responsibility rupture: even if discovered, it is unclear and cannot be held accountable
Even if a token/service account is discovered, it often lacks key context: which application/workload it belongs to, the actual frequency and behavior of use, which resources and permissions are associated with it, and who the corresponding responsible person is.
In the AI Agent scenario, the problem is more acute: it represents who acts, who has access, who is responsible when something goes wrong, and lacks an enforceable attribution and responsibility mechanism.
(5) Control the risk of landing resistance: Failure to control will lead to more hidden detours
Risk patterns tend to be normalized: over-authorization, shared credentials, hard-coded keys, cross-environment access, residual integration after resignation, and long-term existence of orphan status.
“One-size-fits-all disabling of AI/automation” is usually not feasible: businesses will bypass control through Shadow IT/Shadow AI, making risks more hidden and difficult to regulate.
Scheme Introduction
Token Security takes NHI governance as the main line, unifies the identities and credentials scattered in cloud, SaaS, CI/CD, Vault, IdP/SSO and GenAI related environments in enterprises, and extends to cover new automation entities such as AI Agent and MCP Server. Token Security forms a unified Agent/MCP and NHI view through log access and API, then uses algorithms to conduct correlation analysis and risk ranking on the relationship between identity, authority and use, and finally promotes rectification of the problems found through work orders/processes/integration capabilities [5] (see Figure 4).
Figure 4 Token Security NHI Governance Scheme
3.1 Scheme Architecture
The hierarchical design of “multi-source access → real-time inventory → risk engine → risk map” is adopted as a whole [6] (see Figure 5): the underlying layer widely accesses enterprise technology stack signals, forming a continuously updated NHI asset view in the middle, and the upper layer transforms permissions and dependencies into computable and interpretable risks and governance priorities.
Data source access layer: connects Cloud, CI/CD, IAM, GenAI, database, On-Prem, Vault/Secrets, SaaS and other domains to continuously collect NHI objects, credential forms, permission configuration and usage clues to provide original facts for cross-system association.
Real-time contextual NHI inventory layer: Aggregate, deduplication and unify modeling of multi-source signals to generate a real-time NHI list, and complete the context for each NHI as the foundation for subsequent risk calculations.
NHI risk engine layer: Calculate and sort risks on top of inventory, focus on over-authorization, long-term valid secrets, shadow/unfederated accounts, third-party connection exposure, sensitive system access paths, etc., output executable priority and evidence chains, and support risk-based governance.
NHI risk map layer: presents the relationship of “NHI-authority-resource-dependency/call chain” in a graph, and promotes point discovery to path-level insight, which is convenient for locating risk sources and the shortest repair path (convergence authority, replacement credentials, disconnection of high-risk links, etc.).
Figure 5 Token Security Solution Architecture
3.2 Technical Implementation
Token Security can continuously discover Agents and MCP Servers in the enterprise environment and synchronize inventory of their actual NHI. Secondly, Token Security forms an interpretable contextual risk assessment by uniformly modeling ownership, access links, permissions and credentials to locate over-authorization, idle permissions, shadow assets and intention deviation; Through intent-driven permission control, combined with policies and continuous compliance audits, linkage permission revocation, rotation and isolation are carried out to ensure that rectification is executable, verifiable and traceable [7] (see Figure 6).
Figure 6 Ensuring Large-Scale Agent/MCP Security
(1) Continuous discovery: continuous inventory of Agent/MCP assets and NHI dependencies
Token Security can discover the relationship between Agent/MCP assets, extract the authentication materials (API keys, tokens, OAuth, etc.) in its configuration into NHI, and then associate them with human identities, and finally fall into an executable inventory and risk map.
Endpoint side (MCP/Claude Code/IDE): Forensic analysis is performed through “EDR log location connection relationship + remote configuration acquisition”. Token Security deeply integrates endpoint and identity ecology (such as CrowdStrike), which can continuously scan the environment and perform forensic analysis. Specifically, Token Security can analyze IDE and Claude Code instance information through CrowdStrike logs, and locate which MCPs these processes are communicating with to achieve MCP inventory. In addition, when new MCPs appear in the environment, Token Security can also achieve near real-time discovery and inventory [8] (see Figure 7).
Figure 7 MCP service inventory based on CrowdStrike logs
Platform side (Custom GPT/Managed Agent): Token Security has open-sourced a command line tool for GPT compliance review-GPTs-Compliance-Insight[9]. The tool uses OpenAI’s compliance API to automatically generate clear, concise and structured reports on GPT configuration, shared users and associated files, thereby achieving efficient audit and risk assessment (see Figure 8). It should be noted that GCI requires an OpenAI Enterprise account with compliant API access rights, and the standard version of OpenAI accounts cannot use this API.
Figure 8 Operation Effect of GPT Compliance Review Based on GCI
(2) Risk identification: “Contextual risk scoring” and attribution for Agent/MCP
Token Security can remotely pull configurations such as claude_desktop_config.json and mcp.json (see Figure 9) through CrowdStrike RTR (Real Time Response), forming an evidence chain of “log discovery → configuration forensics → parsing and analysis”.
Figure 9 Hard-coded credential information in the Agent/MCP configuration file
Context modeling data structure: Token Security will classify MCP Server based on authentication methods and output context information such as running location, connection method, accessible systems/data, etc. The risk map is used to express “where it is connected and how large the permission reach is”, and the scoring object is specific from a certain MCP Server to the edge and node of “an instance on a certain endpoint → a certain system”.
Over-authorization/idle permissions: Token Security cross-correlates “static permission configuration” with “runtime” to obtain authorization gaps (such as “90 days of read-only but still retain write permissions”), and then removes over-authorization and idle permissions (see Figure 10).
Figure 10 MCP/Agent Access Permission Analysis
Attribution link: Token Security proposes to use the “Chain Of Custody Logs” method to record the “origins and consequences” of each product (Artifact) and each key action into a traceable, accountable and reviewable timeline: Who, at what time, with what input/context, what tools/authorities were called, what operations were done on which resources, and what outputs were produced can be traced all the way to human identity (see Figure 11).
Figure 11 MCP/Agent Attribution Chain Analysis
(3) Response governance: intent-driven minimum permission + policy-based compliance + automatic repair closed loop
In the governance link of Token Security, “response” is not to issue a work order after discovering risks, but to make identities and permissions an executable control plane. Token Security can make decisions for each Agent/MCP trigger access in combination with context and risk threshold, and write the decision results (release, demotion, revocation, repair) back to the source of permissions and configuration to form a closed loop.
Intent-driven least privilege: The governance point is placed “at the moment of action”. The system uses the Agent’s intent together with the current risk context for authorization judgment, avoiding a static authorization model of “one-time grant upon launch and no review thereafter”; when risks rise or behavior deviates, the control plane needs to have the ability to “automatically shrink permissions”, not just expand them.
Strategic compliance: Implement compliance requirements into executable policies, and record “identity-related events and approval chains” through tamper-proof audit logs, converge the cross-account/cross-system permission lifecycle into retrievable evidence, and support post-event traceability and continuous compliance verification.
Automatic repair closed loop: When the risk exceeds the threshold, the system can automatically route the alarm to the responsible person with executable repair instructions, generate disposal steps, and advance the repair from “recommendation” to “implementable change” (see Figure 12).
Figure 12 NHI Security Governance and Response
3.3 Scheme Features
Token Security builds an end-to-end closed-loop product solution of “discovery-governance-detection response” around NHI governance in new automated subject scenarios such as AI Agent and MCP Server:
Agent/MCP integrated management object: In addition to the traditional NHI (key/secret/service account), it covers the discovery and inventory of AI Agent, MCP Server, Tools/Actions, and establishes a unified relationship link and visibility.
Implementation of call chain-oriented governance: Take call dependency as the context to perform minimum permission convergence, configuration baseline and drift governance, and implement life cycle actions such as attribution, rotation/short-termization, idle recycling into specific Agent/MCP assets and change processes.
Detection response is closer to the semantics of Agent behavior: Combined with running status signals, tool calls and cross-system access are detected for anomalies and risk ranking. It supports one-click linkage, docking work orders, SOAR and other automated repairs, forming a closed loop and verifying the rectification effect.
3.4 Lateral Comparison
In cloud security governance, CSPM mainly addresses “whether cloud resources are configured according to best practices/compliance baselines”, and CIEM mainly addresses “whether the identity and permissions on the cloud are excessive and whether they meet the minimum permissions”. However, when enterprises introduce “automated executors” such as AI agents/MCPs, risks often no longer come only from cloud resource misallocation or IAM role design, but from the distribution and use of credentials/Tokens, permission boundaries for non-human identities, and whether cross-agent call links are traceable and constrained. Token Security is more like access surface governance and audit traceability around “Agent/MCP-NHI”, which complements CSPM and CIEM (see Table below).
Dimensions
Token Security(Agent/MCP/ NHI)
CIEM (authority governance)
CSPM (Configuration and Compliance)
Core governance objects
Token, API key, OAuth app, Service account/NHI; and agent/tool call link
Cloud IAM entities and permissions (roles/policies/entitlements)
Cloud resource configuration and security baseline (network, storage, encryption, logs, etc.)
Main problems to be solved
VC leakage/abuse, excessive NHI authorization, too wide third-party OAuth scope, unauthorized and untraceable agent runtime
Permission creep and minimum permission, permission reachable path/lateral movement risk
Resource misconfiguration, configuration drift and lack of compliance control
Control point (detection vs operation period)
More emphasis on “when the call occurs” constraints and rapid revocation/rotation (incorporating Agent/MCP behavior into the governance closed loop)
Most of them focus on evaluation and governance
Mainly based on continuous detection and (partial) automatic repair configuration
Traceability and audit granularity
Tend to string “who/which agent + which token used + what tool called + what output” into a chain of evidence
Partial authority change/use audit, authority relationship and path explanation
Partial configuration item changes, compliance reports and audit evidence
The most suitable landing scenario
SaaS/OAuth/Token rampant; NHI surges; AI agent/MCP ecosystem needs to be traceable and constrained
Multi-Cloud IAM Permission Governance and Least Privilege Project
Compliance baseline construction, cloud resource security check and continuous compliance
Summary
Overall, Token Security is more like an identity security governance and detection response platform for NHI in the era of Agentic AI. It shifts the focus from the traditional “how people log in and authenticate” to “how Agent/MCP gains access, what is actually accessed, where risks are exposed, and how to controllably repair it in an engineering way.”
In terms of product capability structure, its route clearly follows the “three-step”: The first step is to solve “seeing”-through continuous discovery and inventory, the Agent/MCP and its callable NHI are assetized and traceable, and their distribution, purpose and usage scenarios are clarified; The second step is to solve the problem of “understanding”-use Identity Graph to string “identity-credentials-authorities-resources-dependencies-attribution-behaviors” into an evidence chain, output an interpretable impact surface, and make risks no longer stay at the list level; The third step is to solve the problem of “changing and continuously preventing”-transform risk items into executable governance tasks, shorten the attack window with runtime detection and response, and feed the event conclusions back to the governance strategy to form a closed loop of continuous convergence.
References
[1] https://www.token.security/
[2] https://councils.forbes.com/profile/Itamar-Apelblat-CEO-Co-Founder-Token-Security-Token-Security/6eaf4ebe-8b6f-432f-8156-8a96665d7031
[3] https://www.token.security/research
[4] https://nhiguide.ai/overview/what-is-nhi
[5] https://www.token.security/assets/token-security-one-pager
[6] https://www.token.security/assets/securing-non-human-identities-and-agentic-ai
[7] https://www.token.security/use-cases/ai-security
[8] https://www.token.security/blog/token-security-mcp-server-discovery-capability-uncovers-hidden-ai-servers-and-secrets
[9] https://github.com/tokensec/gpts-compliance-insight
The post RSAC Innovation Sandbox | Token Security： Advocate of the Machine-First Identity Security Concept appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..
*** This is a Security Bloggers Network syndicated blog from NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks. authored by NSFOCUS. Read the original post at: https://nsfocusglobal.com/rsac-innovation-sandbox-token-security%EF%BC%9A-advocate-of-the-machine-first-identity-security-concept/
About Author
