Target Domain Management: Establish the Authorized WordPress Scope Before You Scan
Aegisify Target Domains is the control layer that ties a WordPress site to the correct subscription, organization, administrators, Agent connection, verification state, and active dashboard context. Before security evidence for example.com can be trusted, Aegisify needs to know that the site is authorized and that the WordPress-side Agent belongs to the domain it claims to represent.
How a WordPress Site Becomes an Authorized Aegisify Target
This public diagram explains the control model without exposing private credentials, verification values, Agent endpoints, or connection mechanics.
Click a stage to expand
01SubscriptionCapacity + status
02Add Domainexample.com
03Connect AgentPer-domain trust
04Validate IdentityDomain must match
05VerifyAgent or optional DNS
06Set ContextAuthorized session
Target Domains Is the Authorization and Scope Layer—Not a Security Scanner
Adding or verifying a domain does not by itself run vulnerability, SAST, DAST, malware, logging, or risk-intelligence jobs.
The Target Domains feature establishes which WordPress sites belong to the current Aegisify account and which sites the current user is allowed to operate. That scope is reused by scans, logs, reports, plugin intelligence, Agent evidence, and dashboard views so the application can keep information attached to the correct environment.
The supplied implementation also separates domain verification from Agent connection status. A domain can begin pending, become verified through the Agent, or be verified through the optional DNS method. Agent state remains visible independently because a domain can still need troubleshooting even after ownership has been established.
Domain Capacity and Changes Are Managed as Account Resources
Subscription Context
The domain-management view exposes the current plan and account status so administrators can understand the commercial context that controls whether new targets can be added.
Domains Used vs. Allowed
Aegisify compares the organization’s current domain usage with the plan’s maximum domain allowance before accepting another active site.
Domain Changes Used and Remaining
The current implementation tracks account-level domain changes and the remaining allowance. Removing a domain so another can replace it is treated as a meaningful subscription change rather than an unlimited free reset.
Root and Admin Domain Administration
Adding domains and viewing sensitive Agent connection controls are restricted to organization Root and Admin roles. Other team members can be permitted to work with authorized domain evidence without receiving the same domain-administration powers.
Connecting the Agent Establishes More Than Availability
The Agent connection becomes a trust signal only after Aegisify verifies that it belongs to the intended site.
Per-Domain Connection Credential
Aegisify issues a separate security credential for the domain. Administrators place that credential in the Audit Agent on the WordPress site they intend to connect. The value itself should never appear in public documentation, screenshots, support posts, or marketing examples.
HTTPS Agent Connection
The SaaS platform connects to the Agent over HTTPS and validates the remote WordPress identity. The implementation rejects a connection when the Agent API host or the WordPress domain reported by the Agent does not correspond to the domain saved in Aegisify.
Successful Connection Can Verify the Domain
Once the Agent connection is authenticated and its domain identity is accepted, the current implementation can mark the Target Domain as verified by Agent. This removes a separate verification step for customers who are already deploying the Agent.
DNS Provides a Second Verification Method
Agent verification is the primary operational path in this feature, while DNS TXT verification remains available as an optional ownership method.
The public documentation should describe DNS verification at a conceptual level: Aegisify provides a domain-specific TXT value, the authorized administrator publishes it through the domain’s DNS provider, and the platform verifies that the expected record is present.
The exact token structure is intentionally not reproduced here. A DNS value is an ownership-verification artifact, not a marketing example.
The Selected Target Follows the User Through the Dashboard—Within the Current Login Session
The same domain context is reused by other Aegisify views so users do not have to repeatedly reselect a site as they move through the application.
The current implementation stores the selected Target Domain in a way that is scoped to the current authenticated login session. A new login receives a new session context, so the domain selected during an earlier login is intentionally not blindly reused. If the current session has no valid selection, Aegisify resolves the first domain the user is authorized to access.
Every explicit selection is authorization-checked. If a domain is removed or the user’s access changes, a stored selection is not enough to keep access. The selected domain must still appear in the user’s current authorized domain set.
Four Signals Help Explain the Current State
Agent Connectivity Has Its Own Activity History
The domain-management feature retains recent Agent connectivity and verification activity to support troubleshooting without turning the public guide into an implementation map.
Connection Checks
Recent Agent activity can indicate whether SaaS attempted to reach the remote Agent and whether the resulting connection state was successful or failed.
Identity Attempts
Verification-related activity helps administrators distinguish a general connectivity problem from a site-identity or domain-verification problem.
Troubleshooting Detail
Operational context can be retained for authorized troubleshooting, but public documentation should not expose private remote responses, credentials, internal request details, or other sensitive connection artifacts.
Target Domain Management Does Not Enable or Collect Them Automatically
The domain page establishes the target and Agent trust relationship. It is not the place where security evidence collection is automatically turned on.
After the Agent is connected, other Aegisify features can request the types of evidence they are designed to use—such as inventory, WordPress Activity Log data, approved telemetry, static analysis results, or other Agent-assisted evidence. Those workflows remain subject to their own feature behavior and Agent-side authorization.
Likewise, selecting example.com as the active Target Domain tells later views which authorized site to operate against; it does not silently launch a scan. Vulnerability, SAST, DAST, logging, and intelligence actions remain explicit workflows.
What Public Documentation Should Never Expose
Domain setup is one of the places where documentation can accidentally reveal secrets that do not belong on a public website.
This page intentionally excludes private Agent credentials, exact Agent API routes, verification values, private connection responses, internal identifiers, and implementation-specific request mechanics. Customers see the necessary values after authentication; search engines and anonymous visitors do not need them.
Common Questions About Aegisify Domain Management
Does adding a Target Domain start a security scan?
No. Domain management establishes authorized scope and the connection/verification state. Security scans and evidence-collection workflows are separate actions.
Who can add domains and access Agent connection controls?
The supplied implementation restricts domain administration and sensitive Agent connection controls to organization Root and Admin roles. Other users receive domain access according to the account’s authorization model.
Is DNS verification required when the Agent connects successfully?
No. The current page states that a valid authenticated Agent connection can verify the domain automatically and that DNS TXT verification is optional.
Why does Aegisify validate that the Agent matches the saved domain?
Because Agent evidence is meaningful only when it belongs to the intended WordPress target. The implementation rejects mismatched Agent/domain identity rather than attaching evidence to the wrong site.
Does the active domain selection persist forever?
No. Front-end domain selection is scoped to the current authenticated login session and remains authorization-checked. A new login establishes a fresh session context instead of blindly reusing the previous session’s target.